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1^  Please  consider  the  environment  -  do  you  really  need  to  print  this  document!? 

Remarques: 

Pour  qu'il  soit  utilisable  d'une  manière  rationnelle  et  sans  danger  ce  support,  qui  constitue  un 
"super  condensé"  d'un  exposé  qui  tiendrait  très  facilement  sur  plusieurs  milliers  de  pages  (voir 
les  ouvrages  de  cette  taille  disponible  sur  le  commerce),  doit  absolument  être  complété  par  de 
nombreuses  notes  et  exposés  oraux,  au  cours  desquels  les  notions  nouvelles  sont  présentées  au 
moyen  de  situations  (exercices)  concrètes  et  illustrées  par  de  nombreux  exemples  dont  le 
choix  dépend  essentiellement  du  déroulement  de  la  formation  afin  d'exciter  l'esprit  critique 
des  apprenants.  Ce  support  correspond  à  une  formation  d'environ  50  jours  à  6.5  heures  par 
jour  pour  un  groupe  de  6  à  8  personnes. 

Attention!!!  Pendant  les  séminaires  et  conférences  de  moins  ou  égal  à  3  jours  je  prends 
oralement  et  délibérément  des  raccourcis  dangereux  voire  parfois  partiellement  faux 
délibérément  à  cause  du  manque  de  temps  pour  aller  dans  les  détails.  Ce  support  permet  donc 
aux  participants  intéressés  de  corriger  le  tir  pour  éviter  les  P.F.D.A.1. 

Je  tiens  également  à  préciser  que  ce  document  est  censé  être  utilisé  conjointement  avec  celui 
sur  le  logiciel  de  gestion  de  projets  MS  Office  Project  contenant  uniquement  les  captures 
d'écran  de  la  version  anglophone  de  MS  Project  2000/2002/2003/2007/2010/2013.  Le  choix 
de  la  langue  anglaise  intervient  quant  au  fait  que: 

1 .  C'est  celle  dont  il  est  fait  le  plus  usage  dans  la  littérature  spécialisée  et  dans  la  pratique 
il  ne  serait  donc  pas  convenable  d'essayer  de  s'y  soustraire.  Par  ailleurs,  les  pays 
francophones  ont  souvent  un  demi-siècle  de  retard  par  rapport  aux  méthodes  et 
techniques  de  gestion  de  projets  publiées  dans  la  langue  de  Shakespeare. 

2.  Il  y  a  plusieurs  erreurs  de  traduction  dans  la  version  française  du  logiciel  qui  sont  en 
partie  ridicules  et  certaines  même  dangereuses! 

3.  Travailler  dans  un  environnement  multilingue  avec  ce  logiciel  est  peu  agréable,  donc 
l'anglais  s'impose  de  lui-même 

4.  L'anglais  est  la  langue  de  référence  depuis  plus  d'un  siècle  pour  les  scientifiques  et 
ingénieurs.  Il  s'agit  donc  un  acquis  minimum  pour  tout  diplômé. 

Il  y  a  de  nombreuses  marques  déposées  qui  sont  nommées  dans  le  présent  support.  Plutôt  que 
d'utiliser  le  symbole  du  trademark  sur  chaque  occurrence  de  marque  nommée,  j'ai  choisi 
d'utiliser  le  nom  seul  uniquement  dans  un  souci  d'esthétique  éditoriale  (ce  qui  devrait  aussi 
bénéficier  au  propriétaire  de  la  marque),  sans  aucune  intention  de  violer  une  quelconque 
réglementation  ou  législation.  Certaines  images  sont  prises  d'Internet  sans  avoir  pu  identifier 
en  identifier  avec  certitude  les  auteurs.  Dans  le  cas  d'une  réclamation  de  violation  de  droits 
d'auteurs,  nous  retirerons  bien  évidemment  immédiatement  l'illustration  du  présent  document. 

Il  faut  donc  considérer  d'une  façon  générale,  tous  les  produits  ou  illustration  cités  dans 
l'ouvrage  concernant  un  acteur  du  marché  font  l'objet  d'un  copyright  par  leurs  éditeurs/auteurs 
respectifs  et  qu'ils  ont  le  droit  d'en  demander  le  retrait. 
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Pour  terminer,  je  souhaiterais  remercier  ici  les  quelques  collègues  et  clients  qui  ont  bien  voulu 
me  faire  part  de  leurs  remarques  pour  améliorer  le  contenu  de  ce  livre  électronique.  Il  est 
cependant  certain  qu'il  est  encore  perfectible  sur  de  nombreux  points... 

Si  vous  souhaitez  être  informé  des  nouvelles  versions  majeures  de  ce  document  n'hésitez  pas 
à  m'écrire  un  e-mail  dans  ce  sens:  isoz@sciences.ch. 


La  Théorie, 

c'est  quand  on  comprend  tOUt 
et  que  flCIl  ne  marche. 

La  Pratique, 

c'est  quand  tout  marche, 

mais  on  ne  sait  pas  pourquoi. 

Ici 

nous  avons  réussi  les  deux  : 
rien  ne  marche 
et  personne  ne  sait  pourquoi. 
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1.  Introduction 

La  mise  en  place  d'un  projet  est  un  des  enjeux  fondamentaux  pour  les  entreprises  et  les 
organismes  soucieux  d'optimiser  l'utilisation  de  leurs  ressources  humaines  et  matérielles. 

Ce  support  a  pour  objectif  d'introduire  aux  techniques  quantitatives  et  méthodes  de  gestion  de 
projets  dont  la  "maîtrise"  est  indispensable  aux  cadres  de  l'entreprise  moderne  et  s'adresse 
principalement  aux  étudiants  en  2eme  et  3eme  cycles  universitaires  dans  un  domaine  scientifique 
ou  de  gestion  de  projets  d'ingénierie  (selon  le  standard  franco-français.  Il  intéressera 
également  les  praticiens  d'entreprises,  responsables  de  projets  ou  personnes  participant  à  un 
projet,  désireux  d'acquérir  ou  de  compléter  leurs  connaissances  en  gestion  (car  aller  au  fond 
des  choses  est  une  vertu  bien  rare...)  particulièrement  pour  la  partie  quantitative 
(mathématique).  Ce  support  a  l'intérêt  majeur  aussi  de  présenter  des  boîtes  à  outils 
opérationnelles,  traitant  d'aspects  méthodologiques  mais  aussi  comportementaux,  dans 
lesquelles  les  différents  professionnels  peuvent  piocher  afin  de  déployer  leurs  dispositifs  de 
gestion. 

J'insiste  particulièrement  sur  la  partie  quantitative  car  comme  disait  un  prix  Nobel 
d'Économie:  Ceux  qui  ne  peuvent  faire  de  la  science,  font  de  la  méthodologie .  Raison  pour 
laquelle  le  95%  des  ouvrages  de  gestion  de  projets  ne  font  que  de  la  méthodologie...  Donc  il 
n'est  pas  étonnant  que  la  majorité  des  projets  soient  mal  gérés  quand  on  sait  que  la  majorité 
des  gestionnaires  actuels  ont  appris  des  méthodes  dont  le  niveau  intellectuel  d'apprentissage  et 
d'application  ne  nécessite  pas  un  niveau  supérieur  à  celui  du  lycée...  (et  je  peux  prouver  que 
c'est  le  cas!). 

Tant  que  la  gestion  de  projets  n'utilisera  pas  des  méthodes  scientifiques,  nous  en  resterons  à 
des  méthodes  qu'utilisaient  la  médecine,  l'astronomie,  la  biologie,  la  chimie  (alchimie),  à  la 
fin  du  I7eme  siècle...  et  cela  ne  leur  avait  pas  réussi  puisqu'elles  régressaient  au  lieu  d'évoluer. 
Ce  n'est  qu'après  avoir  adopté  les  méthodes  scientifiques  que  tous  les  domaines  précités  ont 
explosé  en  termes  de  fiabilité,  d'innovation  et  de  rigueur. 


Le  contenu  de  cet  ouvrage  est  un  livre  de  recettes,  mais  cependant  il  est  peut-être  bon  de 
rappeler  qu'une  bonne  mise  en  pratique  des  outils  de  la  gestion  de  projets  nécessite  les 
conditions  cadres  minimales  suivantes: 

1 .  Le  soutien  de  la  direction  (sinon  quoi  toutes  les  autres  conditions  tombent  à  l'eau) 

2.  La  formation  des  personnes  impliquées 

3.  Des  rôles  tenus  par  les  meilleurs  spécialistes  pour  une  bonne  évaluation  du  travail 

4.  La  même  compréhension  par  le  donneur  d'ordre  et  le  responsable  du  projet 

5.  Une  grande  clarté  au  niveau  de  ressources  utilisables  et  de  leurs  restrictions 

6.  La  mise  en  place  des  prérequis  au  déroulement  du  projet  (processus,  modèles,  etc.) 

7.  L'adaptation  de  ces  outils  à  la  situation  spécifique  du  projet  (tailoring) 

Ceci  étant  dit...  allons-y! 


Toujours  avoir  au  moins  3  coups  d'avance 
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V 

1.1  A  propos  du  rédacteur 

Nom  Prénom:  ISOZ  Vincent 
Domicilié  à  ce  jour  à  Lausanne  (Suisse) 

Formation:  Ingénieur  Physicien  HES  (B.Sc.) 

Équivalence  Internationale:  Bachelor  of  Science 

Année  de  naissance:  1978 

E-mail:  isoz@sciences.ch 

J'ai  une  formation  scolaire  que  l’on  peut  qualifier  comme  étant  spécialisée  dans  la  physique  et 
chimie  nucléaire.  C'est  un  domaine  où  la  gestion  de  projets,  les  processus,  le  contrôle  des 
risques,  la  rigueur  et  le  niveau  de  compétence  est  probablement  le  plus  élevé  à  ce  jour  sur 
notre  planète  (j'y  reviens  plus  en  détails  dans  la  partie  dédiée  à  la  gestion  des  risques). 

Actuellement,  je  suis  consultant  trilingue  (français,  anglais  et  allemand)  en  mathématiques 
appliquées  dans  le  tutorat  d'analystes  quantitatifs  (niveau  Bac+5  à  Bac+7)  et  auteur  de 
plusieurs  livres  électroniques  dans  les  domaines  suivants: 

-  maîtrise  statistique  des  processus/procédés  (méthodes  paramétriques  et  non  paramétriques) 

-  modélisation  prévisionnelle/décisionnelle  avancée  (arbres  de  décisions,  chaînes  de  Markov) 

-  recherche  opérationnelle  (simplexe,  algorithmes  génétiques,  algorithme  GRG) 

-  data  mining  (réseaux  de  neurones,  ACP,  AFC,  régressions,  scoring,  clustering,  etc.) 

-  modélisation  du  risque  en  gestion  de  projets  et  finance  d'entreprise  (monte-carlo,  etc.) 

-  gestion  de  projets  (modèles  et  best  practices  théoriques  EFQM+Six  Sigma,  MS  Project) 

-  ISO  9001:2008,  5807:1985,  10015:1999,  31000+31010:2009,  8258:1991,  10017:2003,  etc. 

-  Adobe  Photoshop  et  Illustrator 

-  12  applications  de  la  suite  Microsoft  Office  System  (Project,  Visio,  SharePoint,  Access,  etc.) 

À  ce  jour  interventions  dans  plus  de  -200  entreprises  dont  10  du  Fortune  500  selon  listing 
2009  et  3  universités  et  écoles  d'ingénieurs  suisses  dans  des  cours  de  modélisation  de  bases  de 
données  et  simulations  stochastiques  du  risque.  Formation  de  plusieurs  dirigeants  de 
multinationales  en  one  to  one. 

Accessoirement  j'interviens  pour  des  formations  sur  des  logiciels  comme  MS  Project, 

MS  Visio,  MS  Access  et  une  vingtaine  d'autres  dont  je  délègue  l'organisation  à  des  entreprises 
spécialisées  dans  la  formation  continue  en  bureautique  (niveau  licence  et  en-dessous). 

Enfin,  je  conseille  aussi  vivement  à  toute  personne  souhaitant  vraiment  maîtriser  le  sujet  de 
lire  mon  e-book  sur  MS  Office  Project  (-900  pages)  ainsi  que  celui  sur  les  Mathématiques 
Appliquées  (~5'000  pages)  et  Minitab  (~1'300  pages). 
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1.2  Avertissements 

Le  contenu  du  présent  support  est  élaboré  par  un  processus  de  développement  par  lequel  des 
experts  de  la  gestion  de  projets  parviennent  à  un  consensus.  Ce  processus  qui  rassemble  des 
participants  bénévoles  recherche  également  les  points  de  vue  de  personnes  intéressées  par  le 
sujet  de  cet  ouvrage.  En  tant  que  responsable  du  présent  support,  j'assure  l'administration  du 
processus  et  je  fixe  les  règles  qui  permettent  de  promouvoir  l'équité  dans  l'approche  d'un 
consensus.  Je  me  charge  également  de  rédiger  les  textes,  parfois  de  les  tester/évaluer  ou  de 
vérifier  indépendamment  l'exactitude/solidité  ou  l'exhaustivité  des  informations  présentées. 

Je  décline  toute  responsabilité  en  cas  de  dommages  corporels,  matériels  ou  autres  de  quelque 
nature  que  ce  soit,  particuliers,  indirects,  accessoires  ou  compensatoires,  résultant  de  la 
publication,  de  l'application  ou  de  la  confiance  accordée  au  contenu  du  présent  support.  Je 
n'émets  aucune  garantie  expresse  ou  implicite  quant  à  l'exactitude  ou  à  l'exhaustivité  de  toute 
information  publiée  dans  le  présent  support,  et  ne  garantit  aucunement  que  les  informations 
contenues  dans  cet  ouvrage  satisfassent  un  quelconque  objectif  ou  besoin  spécifique  du 
lecteur.  Je  ne  garantis  pas  non  plus  les  performances  de  produits  ou  de  services  d'un  fabricant 
ou  d'un  vendeur  par  la  seule  vertu  du  contenu  du  présent  support. 

En  publiant  des  textes,  il  n'est  pas  dans  l'intention  principale  du  présent  support  de  fournir  des 
services  de  spécialistes  ou  autres  au  nom  de  toute  personne  physique  ou  morale  ni  pour  mon 
compte,  ni  d'effectuer  toute  tâche  devant  être  accomplie  par  toute  personne  physique  ou 
morale  au  bénéfice  d'un  tiers.  Toute  personne  utilisant  le  présent  support  devrait  s'appuyer  sur 
son  propre  jugement  indépendant  ou,  lorsque  cela  s'avère  approprié,  faire  appel  aux  conseils 
d'un  spécialiste  compétent  afin  de  déterminer  comment  exercer  une  prudence  raisonnable  en 
toute  circonstance.  Les  informations  et  les  normes  concernant  le  sujet  couvert  par  le  présent 
support  peuvent  être  disponibles  auprès  d'autres  sources  que  le  lecteur  pourra  souhaiter 
consulter  en  quête  de  points  de  vue  ou  d'informations  supplémentaires  qui  ne  seraient  pas 
couverts  par  le  contenu  du  présent  document. 

Je  ne  dispose  (malheureusement...)  d'aucun  pouvoir  dans  le  but  de  faire  respecter  la 
conformité  au  contenu  du  présent  ouvrage,  et  je  ne  m'engage  nullement  à  surveiller  ni  à  faire 
respecter  une  telle  conformité.  Je  n'exerce  (à  ce  jour...)  aucune  activité  de  certification,  de  test 
ni  d'inspection  de  produits,  de  conceptions  ou  d'installations  à  fins  de  santé  ou  de  sécurité  des 
personnes  et  des  biens.  Toute  certification  ou  autre  déclaration  de  conformité  en  matière 
d'informations  ayant  trait  à  la  santé  ou  à  la  sécurité  des  personnes  et  des  biens,  mentionnée 
dans  le  présent  support,  ne  peut  aucunement  être  attribuée  au  contenu  du  présent  support  et 
demeure  sous  l'unique  responsabilité  de  l'organisme  de  certification  ou  du  déclarant  concerné. 
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1.3  Comment  utiliser  ce  livre 

Dans  le  cadre  des  études  supérieures,  ce  livre  peut  être  utilisé  pour  des  séminaires  de  niveau 
licence,  master  ou  doctorat  dans  de  nombreux  domaines  des  sciences  pures  et  exactes.  Les 
séminaires  dans  lesquels  nous  utilisons  ce  matériel  est  une  partie  intégrale  des  programmes  de 
Scientific  Evolution  Sàrl,  où  les  apprenants  ont  déjà  derrière  eux  un  cursus  universitaire  ni 
licence  ou  maîtrise  dans  leur  spécialisation. 

Parce  que  les  méthodes  des  mathématiques  appliquées  s'apprennent  par  la  pratique  et 
l'expérience,  nous  concevons  un  séminaire  sur  MATLAB  comme  un  processus 
d'apprentissage  par  la  pratique.  Nous  structurons  nous  séminaires  de  modélisation 
mathématiques  autour  d'un  ensemble  de  problèmes  qui  requière  aux  apprenants  de  construire 
des  modèles  qui  aident  à  s'organiser  et  à  prendre  des  décisions.  L'important  est  que  les 
modèles  doivent  être  consistants  avec  la  théorie  et  back-testés.  Pour  répondre  à  cet  impératif, 
il  est  nécessaire  pour  l'apprenant  de  combiner  les  mathématiques  théoriques  avec  la 
modélisation.  Le  résultat  est  que  l'apprenant  maîtrise  la  théorie  et,  plus  important,  qu'il 
acquière  les  méthodes  permettant  d'appliquer  la  théorie  à  des  cas  pratiques  réels.  La  capacité 
de  critiquer  et  identifier  les  limitations  d'outils  mathématiques  sensibles  est  la  valeur  ajoutée 
la  plus  importante  de  nos  séminaires. 

Les  problèmes  avec  solutions  dans  le  texte  fournissent  une  opportunité  d'appliquer  les  notions 
théoriques  à  de  petits  cas  pratiques  tirés  ou  inspirés  pour  la  majorité  de  cas  réels.  A  la  fin  des 
séminaires  les  apprenants  ont  amélioré  leurs  compétences  et  connaissances  des  outils 
théoriques  et  computationnels  majeurs. 

Il  est  vraiment  difficile  de  traiter  toute  la  matière  de  ce  livre  en  un  semestre.  Il  faut  beaucoup 
de  temps  pour  expliquer  la  finesse  des  concepts  aux  apprenants.  Le  lecteur  est  alors  encouragé 
de  choisir  les  sujets  qui  lui  sont  nécessaires  pendant  son  temps  d'étude.  Ainsi,  il  n'est  pas 
obligatoire  de  parcourir  les  chapitres  dans  l'ordre  dans  lesquels  ils  sont  présentés  mais  cela 
peut  toutefois  aider  de  façon  significative. . . 

En  un  mot,  ce  livre  offre  une  large  variété  de  sujets  qui  se  prêtent  à  la  modélisation. 
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1.4  Change  Log 

Suite  à  plusieurs  demandes,  j'ai  décidé  de  faire  pour  ce  document  ce  que  j'enseigne  pour  les 
documents  importants  d'un  projet:  un  journal  des  changements  importants  du  document 
avec  un  bref  descriptif  et  daté.  C'est  tout  nouveau  donc  pour  l'instant  donc  forcément  vide. . . 

Ce  document  reflète  aussi  mes  propres  limites  intellectuelles.  Bien  que  je  m'efforce  d'étudier 
autant  de  domaines  scientifiques  et  mathématiques  que  possible,  il  est  impossible  de  tous  les 
maîtriser.  Le  document  indique  clairement  mes  propres  intérêts  et  expériences  en  tant  que 
consultant,  mais  aussi  mes  points  forts  et  mes  points  faibles.  Je  suis  responsable  du  choix  des 
entrées,  ainsi  que,  bien  sûr,  des  éventuelles  erreurs  et  imperfections. 


1  Version 

Description 

Dates  1 

V4.12  R1647 

Ajout  de  quelques  pistes  pour  recruter  ou  identifier  un  responsable  de  projet 
selon  Adecco  Suisse  et  quelques  lignes  concernant  l'analyse  structurelle  + 
types  de  comportements  de  base  en  réunion. 

2011-03-12 

V4.12  R1648 

Ajout  de  la  check-list  de  la  méthode  Hermès  comme  exemple  pertinent  de  ce 
qu'il  est  possible  de  faire  pour  la  gestion  du  cycle  de  vie  d'un  projet. 

2011-03-20 

V4.13  R1649 

Corrections  orthographiques  diverses  et  ajouts  de  quelques  phrases  ici  et  là 
concernant  la  qualité  et  la  finance  de  projets. 

Ajout  de  compléments  d'informations  concernant  la  partie  terminaison 
(clôture)  de  projets  et  suivi  du  changement. 

Enfin,  ajout  de  quelques  remarques  au  début  de  la  partie  bibliographie. 

2011-03-07 

V4.14  R1650 

Dans  le  chapitre  où  je  présente  les  méthodologies  courantes,  j'ai  complété  un 
tout  petit  peu  la  partie  AMDEC  en  indiquant  les  trois  grands  types  d'actions  de 
maintenance.  Toujours  dans  le  même  chapitre,  j'ai  complété  dans  la  partie 
concernant  les  standards  ISO  la  liste  des  standards  que  j'utilise  presque  tous  les 
jours  dans  mon  travail  (suite  au  fait  que  la  question  revient  relativement 
souvent  dans  mes  cours). 

2011-04-08 

V4.15  R1651 

Ajout  d'une  mini-section  concernant  l'approche  qualitative  du  risque  selon  la 
méthode  empirique  de  l'AMDE(C)  et  listing  des  normes  ISO  que  je 
recommande  d'utiliser  dans  le  cadre  de  projets  à  forte  valeur  ajoutée. 

2011-04-17 

V4.15  R1652 

Informations  mon  indépendance  relativement  aux  noms  de  marques,  logiciels, 
livres,  normes,  etc.  que  je  mentionne  dans  le  présent  document. 

Ajout  d'un  chapitre  concernant  la  vente  d'un  projet  lors  de  la  recherche  de 
partenaires  ou  d'investisseurs. 

2011-04-23 

V5.0R1653 

Ajout  des  exercices  de  basés  sur  la  finance  de  projets. 

2011-05-01 

V5.1  R1654 

Compléments  rajoutés  concernant  les  normes  ISO  et  CEI  ainsi  que  sur 
l'analyse  par  arbres  de  défaillance  et  le  bootstrapping. 

2011-06-20 

V5.2R1655 

Ajout  d'applications  numériques  sur  la  gestion  de  la  qualité  et  petite 
introduction  à  la  gestion  de  la  connaissance. 

Ajout  également  des  4  styles  de  communication  selon  le  modèle  du 
psychologue  Jung. 

2011-08-01 

v5.3  R1656 

Ajout  d'un  chapitre  concernant  l'analyse  par  arbres  d'événements  et  ajout  de 
compléments  d'informations  concernant  les  arbres  de  défaillances 
probabilistes. 

2011-08-04 

Ingénierie  de  Gestion  de  projets  14/547 


Vincent  ISOZ 


v5.4  R1657 

Ajout  d'une  page  me  présentant  et  compléments  sur  la  préface.  J'ai  également  2011-12-24 

revu  certains  textes  concernant  Monte-Carlo  et  la  v@r  qui  pouvaient  prêter  à 
confusion  car  pas  clairement  rédigés  (j'espère  que  cela  est  mieux  maintenant). 

V5.5  R 1660 

Correction  de  quelques  fautes  d'orthographe  et  grammaticales  +  restructuration  2012-01-13 
d'un  chapitre  et  ajout  de  quelques  compléments  d'informations  sur  les  B  PF 
(bonnes  pratiques  de  fabrication)  et  le  5M. 

V5.5  R 1662 

Suite  à  la  demande  de  clients  j'ai  rajouté  pour  chaque  méthodologie  de  gestion  2012-03-16 
de  projets  présentée  et  que  j'ai  étudiée  en  détails  le  niveau  scolaire 
correspondant  requis  pour  comprendre  et  maîtriser  la  matière. 

V5.7R1664 

Ajout  de  quelques  compléments  dans  différentes  chapitres  relativement  au  2012-04-16 

PMBOK  ainsi  pour  @Risk  de  Palisade  dans  la  partie  concernant  la  simulation 
du  risque. 

V7.0  R1675 

Ajout  de  quelques  informations  concernant  l'utilisabilité  des  outils  de  gestion  2013-07-13 

de  projets  conformément  à  la  norme  ISO  9241-1 1  et  recommandations  dans  la 
cadre  de  la  phase  de  storming  de  l'équipe  de  projet. 

Ajout  de  quelques  illustrations  concernant  le  domaine  de  la  qualité  et  de  la 
planification. 

Report  de  quelques  exercices  du  cours  sur  l'optimisation  opérationnelle  dans  la 
section  d'exercices  (afin  de  rationaliser  le  nombre  de  documents  distribués  en 
cours). 

v8.0  R1677 

Corrections  orthographiques  et  grammaticales  diverses 

Ajout  d'un  tableau  des  risques  courants  à  considérer  dans  un  projet 

v9.0  R 1679 

Ajout  de  figures  complémentaires  concernant  ITIL. 

Ajout  du  modèle  mathématique  décisionnel  de  l'analyse  procédurale 
hiérarchique. 

Ajout  du  modèle  mathématique  de  VAN  (NPV)  par  processus  binomial 
(options  réelles). 

Changement  de  l'ordre  de  certains  chapitres 

VIO.  R1680 

Ajout  de  compléments  concernant  les  X.B.S. 

Modification  du  titre  du  PDF  pour  indiquer  que  le  contenu  est  vraiment  orienté 
pour  les  scientifiques,  ingénieurs  et  techniciens 
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1.5  Marques  déposées 

En  tant  que  rédacteur  du  présent  document,  je  tiens  à  signaler  que  je  n'ai  aucun  contrat, 
partenariat,  affiliation,  clause  commerciale  ou  intérêt  financier  avec  les  marques  déposées  ou 
noms  d'entreprises,  méthodes,  logiciels  et  livres  que  je  mentionne  dans  le  présent  ouvrage 
électronique. 

J'ai  n'ai  donc  pas  été  agréé  par  qui  que  ce  soit  ou  quoi  que  ce  soit  lors  de  la  rédaction  et  ma 
motivation  se  situe  uniquement  dans  le  but  de  partager  mes  opinions  et  idées  personnelles 
gratuitement  sur  quelques  sujets  élémentaires  dans  la  gestion  de  projets  pour  les  ingénieurs  et 
scientifiques. 

Si  un  représentant  ou  auteur  d'une  marque,  entreprise,  logiciel,  livre  ou  image 
nommée/représentée  dans  le  présent  ouvrage  souhaite  que  j'en  supprime  toute  mention  ou 
représentation,  je  m'exécuterai  alors  immédiatement  et  m'excuse  d'avance  de  ne  pas  avoir 
demandé  l'autorisation  faute  d'avoir  un  département  juridique  à  ma  disposition  pour  effectuer 
ces  démarches. 

1.6  Votre  avis  nous  intéresse! 

En  tant  que  lecteur  de  ce  document,  vous  êtes  le  critique  et  le  commentateur  le  plus  important. 
Votre  opinion  compte  et  il  est  très  intéressant  de  savoir  ce  qui  est  bien,  ce  qui  peut  être  mieux 
et  les  sujets  que  vous  souhaiteriez  voir  être  traités. 

Vous  pouvez  m'envoyer  un  e-mail  pour  partager  ce  que  vous  avez  aimé  ou  détesté  dans  le 
présent  document  afin  d'en  assurer  une  amélioration  continue. 

Notez  que  malheureusement,  je  ne  peux  pas  répondre  gratuitement  à  des  questions  techniques 
d'ingénierie  ou  de  problématique  d'entreprise  par  e-mail  pour  des  raisons  professionnelles 
évidentes. 

E-mail:  isoz@sciences.ch 

1.7  Liens  internet 

Évidemment,  le  présent  ouvrage  et  MS  project  ne  constituent  qu'un  référentiel  et  outil  parmi 
les  nombreux  qui  existent  sur  le  marché.  Pour  plus  d'informations  à  ce  sujet,  nous 
recommandons  la  visite  des  sites  Internet  suivants  vous  proposant  diverses  informations  sur 
la  gestion  de  projets  ainsi  que  des  plug-ins  (payants  ou  gratuits)  pour  MS  Project  Standard/Pro 
ou  Server: 

http://www.iso.org 

Site  de  référence  concernant  les  standards  dans  de  nombreux  domaines  dont  la  gestion  de 
projets  et  de  la  qualité! 

http://www.afnor.org 

Association  Française  de  NORmalisation.  Référence  en  terminologie,  méthodologies  et 
techniques  de  management  dans  de  nombreux  domaines  d'activité. 
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http://www.mpug.org 

The  Microsoft  Project  User  Group  is  a  dynamic  professional  association  that  serves  as  the 
prééminent  resource  for  Microsoft®  Office  Project.  We  help  a  worldwide  community 
comprised  of  thousands  of  individual  and  corporate  members  better  leverage  their  investment 
in  Microsoft  Project  in  their  businesses  and  careers. 

http://blogs.msdn.com/proiect  programmabilitv/default.aspx 

Site  web  pour  les  développeurs  MS  Project  Pro  et  Server.  Attention  niveau  Expert! 

www.gestiondeproiets.com 

Excellent  site.  Contient  en  particulier  un  forum  libre  d'accès  de  très  bon  niveau  avec  de  bons 
conseils. 

www.pmi.org 

Project  Management  Institute  (connu  par  tous!) 
www.sciencesdegestion.com 

Site  en  français  qui  ayant  pour  objectif  de  regrouper  différents  travaux  de  Gaël  Gueguen 
portant  sur  les  recherches  et  les  enseignements  d'un  chercheur  en  sciences  de  gestion.  Il  a 
donc  pour  vocation  principale  le  management  stratégique  des  entreprises,  leur  rapport  avec 
l'environnement  et  l'utilisation  d'Internet  à  des  fins  stratégiques. 

www.mvps.org/proiect 

Site  en  anglais  partenaire  Microsoft  (MVP  signifiant:  Microsoft  Valuable  Professional)  avec 
des  liens,  des  logiciels  compagnons,  des  tutoriaux  sur  MS  Project 

www.managementproiet.com 

Site  en  français  portail  de  la  communauté  des  managers  de  projets,  colloques,  conférences, 
forums,... 

www.aso-organisation.ch 

Site  en  français,  allemand  et  italien  de  l'association  Suisse  d'Organisation  et  de  Management 
(A.S.O.),  séminaires,  actualité,  ... 

www.project-management.ch 

Site  en  français  de  la  société  suisse  de  management  de  projet,  congrès,  bibliographies, 
actualité,... 

www.primavera.com 

Site  en  anglais  proposant  un  logiciel  concurrent  de  MS  Project  parmi  d'autres  (intègre  une 
analyse  des  risques  selon  la  méthode  du  PMBOK) 

www  .proi  ectmanager .  com 

Excellent  système  de  gestion  de  projets  en  ligne  sur  Internet.  Un  bon  moyen  de  substitution  à 
MS  Project  Server  qui  lui  nécessite  de  gros  investissements  en  matière  de  maintenance 
informatique. 

www .  sciforma.  com 

Logiciel  client  (qui  a  priori  n'est  malheureusement  pas  disponible  au  format  web)  qui  semble 
être  pas  mal  du  tout  (en  tout  cas  mieux  que  la  version  cliente  de  MS  Project).  Mais  à  vérifier 
car  je  n'ai  jamais  eu  de  démonstration  détaillée  du  produit. 
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www.ipma.ch 

International  Project  Management  Association 


http  ://  support,  microsoft.  corn/  news  groups 

Forums  officiels  de  Microsoft  et  en  particulier  sur  MS  Project  toutes  version  confondues  (une 
cinquantaine  de  langues  sont  disponibles) 

www.sciences.ch 

Site  francophone  de  référence  mondiale  sur  -  entre  autres  -  les  techniques  mathématiques  de 
gestion  de  projets  et  de  production. 

www.orsoc.org.uk 

Site  anglophone  se  décrivant  comme  société  active  dans  l'étude  de  la  recherche  opérationnelle 
et  les  modèles  mathématiques  de  management.  La  majorité  des  chercheurs  connus  dans  le 
management  ont  publié  dans  leur  revue. 

www.afitep.fr 

Association  Francophone  des  Ingénieurs  Techniciens  en  Planification  et  Gestion  des  risques. 

www  .proi  ectserverexperts.com 
Project  server  expert  community  site 

www  .ilog.  com/products/ganttnet/proi  ectviewer/index .  cfm 

www.afinion.de/english/Products/PoW/APV  2  6.php?navid=7 

Quelque  viewers  gratuits  pour  les  fichiers  MS  Project  (il  en  existe  des  payants  aussi  en  plus 
grand  nombre. . .) 

www.kidasa.com 

Un  outil  de  reporting  pratique  (un  petit  plus)  pour  les  coordinateurs  de  projets  utilisant  MS 
Project  et  souhaitant  générer  des  vues  particulières  de  manière  automatique. 

www.pertmaster.com 

Un  outil  venant  se  greffer  à  MS  Project  pour  la  gestion  de  risques  selon  différentes  modèles 
mathématiques  à  choix. 

www.p2msp.co.uk 

Un  plug-in  très  intéressant  pour  MS  Project  utilisant  la  méthode  Arince  (PM  Methodology).  A 
voir  absolument! 

www.msproject.com 

Propose  un  utilitaire  sympa  pour  les  utilisateurs  de  MS  Office  Project  Serveur  qui  font  du 
Time  Tracking. 

www.bpmn.org  /  www.bmmi.org 

Business  Process  Management  Notation  pour  MS  Visio  (mais  je  recommande  plutôt  le 
logiciel  BizAgi  pour  faire  cela) 

www.bizagi.com  /  www.bonitasoft.com 

Excellents  outils  de  modélisation  et  de  dématérialisation  de  processus  (bien  meilleur  que 
MS  Visio) 
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http://www2.softwareag.com/corporate/products/aris  alfabet/bpa/default.aspx 

Autre  outil  de  modélisation  de  processus  fortement  lié  à  SAP. 

www.chaine-critique.com 

Très  bon  site  qui  explique  de  manière  interactive  la  gestion  de  projets  en  utilisant  la  technique 
de  la  chaîne  critique. 

www.palisade.com  /  www.crystalball.com  /  http://www.intaver.com 

Solution  de  calculs  de  gestion  des  risques  et  arbres  de  décision  ainsi  que  d'analyse  quantitative 
en  utilisant  les  méthodes  de  Monte-Carlo 

http://www.qualios.com  /  http://www.optimiso.com 

Solution  web  et  multilangue  de  la  gestion  de  la  qualité  (processus,  indicateurs, 
documentation)  conforme  à  ISO  9001  et  14001. 

www.logystem.ch 

Société  qui  développe  le  logiciel  QuickControl  Pro  de  gestion  des  contrôles  statistiques  par 
échantillonnage  NQA  selon  les  normes  ISO  2859  et  3951,  correspondant  aux  normes  AFNOR 
et  MILITARY  STANDARD. 

www.dilbert.com 

Pour  ceux  qui  veulent  rigoler  un  bon  coup  car  Adams  caricature  parfaitement  la  gestion  de 
projets,  la  gestion  des  ressources  humaines  et  la  gestion  de  la  qualité  et  des  relations  en 
entreprise. 
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1.8  Bibliographie 

Voici  la  liste  de  quelques  ouvrages  parmi  une  cinquantaine  sur  la  gestion  en  général  que  j'ai  lu 
ces  15  dernières  années  et  dont  je  me  suis  fortement  inspiré  et  que  je  recommande 
chaudement  (d’ailleurs  certains  m'avaient  aussi  été  recommandés  par  des  clients  ou  élèves  et 
j'ai  voulu  en  vérifier  la  qualité)  soit  parce  qu'ils  sont  globalement  excellents  soit  parce  qu'ils 
contiennent  parfois  juste  quelques  pages  avec  des  informations  pertinentes  (les  autres  ne 
valant  pas  la  peine  d'être  mentionnés). 

Je  tiens  également  à  préciser  que  je  ne  cache  pas  que  ma  contribution  se  limite  en  grande 
partie  à  ce  jour  à  celle  d'un  collectionneur  qui  glane  ses  informations  dans  les  ouvrages  des 
maîtres  ou  dans  les  publications  ou  pages  Internet  d'anonymes  et  qui  complète  et  argumente 
les  développements  en  les  améliorant  quand  ceci  est  encore  possible.  Quant  à  ceux  qui 
voudraient  m'accuser  de  plagiat,  ils  devraient  bien  réfléchir  au  fait  que  les  modèles  présentés 
dans  la  plupart  des  ouvrages  payants  et  disponibles  dans  le  commerce  ont  été  découverts  et 
rédigés  par  leurs  illustres  prédécesseurs  et  que  leur  propre  apport  personnel  a  aussi  constitué, 
comme  le  mien,  à  mettre  toutes  ces  informations  sous  une  forme  claire  et  moderne  quelques 
centaines  d'années  plus  tard. 

Le  lecteur  aura  donc  compris  que  je  recommande  très  fortement  de  compléter  la  lecture  du 
présent  e-book  (non  exhaustif  sur  le  domaine  de  la  gestion  de  projets)  par  la  liste  de  lecture  ci- 
dessous. 


NASA  Space  Flight  Program  and  Project  Management  Handbookl 
486  pages  /  Editions  NASA 
ISBN:  9780971032736 

Commentaire:  Ce  le  guide  project  management  de  la  NASA  est  la 
méthode  utilisée  en  interne  par  cette  agence  pour  ce  que  je  considère 
personnellement  comme  les  plus  gros  projets  financiers  et 
technologiques  planétaires  des  cents  dernières  années.  En  terme  de 
complexité  aucun  autre  projet  n'arrive  au  niveau  de  ce  que  fait  la 
NASA  donc  c'est  pour  cette  raison  que  je  ne  peux  que  recommander  à 
ceux  qui  veulent  apprendre  ce  qu'est  l'ingénierie  de  la  gestion  de 
projet  et  la  "vraie"  gestion  de  projets  d'utiliser  cet  ouvrage  comme 
référence  plutôt  que  d'autres  méthodes  comme  le  PMEIPMA/ Agile  et 
autres!!! 


Guide  du  Corpus  des  connaissances  en  mangement  de  projet  (Guide 
PMBOK)  /  389  pages  /  Editions  PMI 
ISBN:  1930699700 

Commentaire:  Donne  de  très  bonnes  bases  conceptuelles  et  de 
vocabulaire  sans  avoir  à  consacrer  des  mois  d'études  et  pour 
commencer  du  bon  pied!  Très  utile  pour  la  culture  générale.  A  garder 
dans  sa  bibliothèque  en  cas  de  conflit  de  principe  de  méthodes  avec 
un  client  ou  un  collègue. 
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Vincent  ISOZ 


Référentiel  de  compétence  VZPM  (Verein  zur  Zertifizierung  von 
Personen  im  Management )  pour  le  management  de  projet,  de 
programme  et  de  portefeuille  en  conformité  avec  les  compétences 
IPMA 

ISBN:  9783859280762 

Commentaire:  Contient  des  dizaines  de  pages  utiles  relatives  au 
comportement  professionnel  d'un  responsable  de  projets  dans  le  cadre 
de  conflits  ou  de  gestion  de  crise  (tables  reprises  dans  le  présent 
document  PDF). 


Sis  Skpiu  et  Minitab 


Six  Sigma  et  Minitab  (QSB  Consulting)  /  235  pages  /  Editions 

Quentin  Book 

ISBN:  9780954681340 

Commentaire:  Donne  un  excellent  petit  aperçu  de  ce  qu'est  la 
méthode  Six  Sigma  avec  des  exemples  pratiques  Minitab. 
Malheureusement,  les  développements  mathématiques  sont  absents 
donc  le  livre  n'est  pas  à  mettre  entre  toutes  les  mains  sinon  quoi  il 
peut  être  fait  un  mauvais  usage.  Un  "must"  quand  même  que  j'ai 
toujours  dans  ma  bibliothèque. 


Techniques 


<ranalyse 

I  de  projets 


Techniques  d’analyse  de  projets  (Gilles  Vallet)  /  199  pages  /  Editions 
Dunod 

ISBN:  2100489127 

Commentaire:  Donne  un  bon  fil  rouge  pour  l’analyse  de  projets. 
Malheureusement,  tire  parfois  en  longueur  certains  sujets  triviaux, 
mais  complète  bien  le  PMBOK.  Quelques  pages  sur  l’ensemble  valent 
la  peine  d’être  parcourues. 


Techniques 
de  planification 
\  de  projets 


Techniques  de  planification  de  projets  (Gilles  Vallet)  /  288  pages  / 
Editions  Dunod 
ISBN:  2100071807 

Commentaire:  Très  orienté  pratique  il  permet  au  lecteur  de  connaître 
les  techniques  de  base  courantes  de  la  planification  comme  le  Gantt 
ou  le  PERT.  Malheureusement,  il  ne  traite  que  des  bases  et  ne  va  pas 
au-delà  de  connaissances  qui  nécessiteraient  une  licence  universitaire. 
On  trouve  facilement  l'équivalent  gratuitement  sur  Internet. 
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Vincent  ISOZ 


Techniques  de  suivi  de  projets:  Assurer  les  conditions  d'achèvement 
d'un  projet  (Gilles  Vallet)  /  298  pages  /  Editions  Dunod 

Commentaire:  Contient  quelques  "astuces"  qui  semblent  être  des 
retours  d'expérience  utiles. . .  Sinon  comme  tous  les  ouvrages  sur  le 
sujet,  c'est  très  théorique  et  applicable  uniquement  par  ceux  qui  font 
de  la  gestion  de  projets  à  100%  de  leur  temps  de  travail 


Statistique  appliquée  à  la  gestion  (Vincent  Giard)  /  560  pages  / 
Editions  Economica 
ISBN:  271784659X 

Commentaire:  Excellent  ouvrage  pour  savoir  quels  sont  les  outils 
statistiques  qui  s'appliquent  à  ce  domaine.  Seul  gros  défaut:  la 
rédaction  est  trop  vieille  et  la  qualité  typographique  des  équations  fait 
que  c'est  très  difficilement  lisible  (c'est  même  parfois 
cauchemardesque) . 


VIHCIMI 

G  FA  R  Ü 
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Gestion  de  la  production  et  des  flux  (Vincent  Giard)  /  1128  pages  / 
Editions  Economica 
ISBN:  2717844988 

Un  énorme  ouvrage,  malheureusement  j'ai  lu  la  version  de  1988  qui 
bien  que  très  intéressante  était  illisible  au  niveau  des  développements 
mathématiques.  Il  paraît  que  la  nouvelle  version  a  été 
considérablement  revue  et  augmentée  d'exemple  pratique  avec  des 
logiciels.  Seul  petit  hic. . .  c'est  que  dans  les  organisations  en  Suisse 
quasiment  personne  ne  connaît  ses  outils  statistiques  chez  les 
dirigeants,  ce  qui  fait  qu'il  est  difficile  de  les  appliquer  vu  le  manque 
d'intérêt. 


- 1 

productifs 

l‘-  vr.wimin  -n 

KnÈiWY 

♦ 


Processus  productifs  et  programmation  linéaire  (Vincent  Giard)  / 
112  pages  /  Editions  Economica 


ISBN:  2717834931 


Recherche  Opérationnelle  et  management  des  entreprises  (Daniel 
Thiel)  /  183  pages  /  Editions  Economica 
ISBN:  2717819304 

Commentaire:  Pour  moi  il  s'agit  du  meilleur  ouvrage  compréhensible 
et  applicable  dans  le  domaine  de  la  recherche  opérationnelle  sans 
avoir  besoin  d'un  doctorat  en  poche.  Son  seul  point  noir  est  d'utiliser 
un  logiciel  spécialisé  pour  les  exemples  alors  qu'il  aurait  été  mieux  de 
se  restreindre  à  MS  Excel  selon  moi.  Il  existe  cependant  des  PDFs 
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gratuits  plus  complets  avec  MS  Excel  sur  le  web  à  notre  époque. 


Statistique  appliquée  à  la  gestion  avec  exercices  corrigés  et 
utilisation  d'Excel  (Vincent  Giard)  /  552  pages  /  Éditions  Economica 


ASIN: 2717829628 


^UtMtjqiK 


DtscTÎpIne 
pour  Im 


Gestionnaires 


Statistique  descriptive  pour  les  gestionnaires  (Vincent  Giard)  /  122 
pages  /  Éditions  Economica 


ISBN:  2717828893 


Gestion 

de 

\  Projets 


Gestion  de  projets  (Vincent  Giard)  /  160  pages  /  Éditions  Economica 
ISBN:  2717821686 


Mathématique 


Financièrns 

fi  Actuarielle* 


Mathématiques  financières  et  actuarielles  (Jean-Pierre  Favre)  /  269 
pages  /  Éditions  Digilex 
ISBN:  29700108110 

Commentaire:  Excellent  livre  sur  le  sujet.  Très  détaillé,  pédagogique 
avec  des  exemples  MS  Excel  ou  macros  à  chaque  fois.  Un  "must"  que 
j'ai  toujours  dans  ma  bibliothèque  tellement  l'ouvrage  est  bon. 


Avinasftk:  dixit 
Robert  S.  Pindyck 


1 1\  V  H  S  T  VI  1  1  \  T 
FMI  I  I! 

IINCERTAINTY 


Investment  Under  Uncertainty  (Avinash  K.  Dixit)  /  482  pages  / 
Éditions  Princeton  University  Press 
ISBN:  9780691034102 

Commentaire:  De  mon  point  de  vue  très  personnel  c'est  la  bible  pour 
ceux  qui  veulent  apprendre  à  évaluer  les  options  d'investissement 
dans  des  projets  en  utilisant  les  options  réelles. 
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Vincent  ISOZ 
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Calculs  commerciaux 
et  bancaires 


Calculs  commerciaux  et  bancaires  (J.Ch.  Corbaz,  D.  Goetschi)  /  232 
pages  /  Imprimerie  Vaudoise 

Commentaires:  Excellent  petit  livre  utilisé  à  l'école  obligatoire 
Vaudoise  dans  les  années  1980  que  j'utilise  pour  former  des  employés 
ou  cadres  supérieurs  dans  les  organisations  qui  ne  savent  plus 
comment  faire  des  règles  de  trois,  des  pourcentages,  des  taux  de 
change,  des  rabais  et  autres  calculs  élémentaires  de  ce  type. . .  qui 
représentent  environ  84%  du  niveau  des  employés  dans  les 
organisations. 


La  modélisation  du  risque  et  simulations  de  Monte-Carlo  (Hervé 
Thiriez)  /  214  pages  /  Éditions  Economica 
ISBN:  2717848223 

Commentaire:  C'est  un  sujet  difficile  à  présenter  sans  un 
accompagnement  en  classe  et  un  logiciel.  Mais  Hervé  Thiriez  s'en 
sort  pas  trop  mal  pour  présenter  le  sujet.  Je  n'ai  pour  l'instant  rien  vu 
de  mieux  en  français  à  ce  sujet.  Par  contre,  une  formation  présentielle 
aura  une  plus  value  non  négligeable  que  la  simple  lecture  de  cet 
ouvrage  qui  reste  très  superficiel  pour  comprendre  les  subtilités  du 
domaine  de  la  modélisation. 


EC 

■  O 

Inilialiu 
j  La  thêc 

n 

trie  des  jjrux 

Initiation  à  la  théorie  des  jeux  (Jean-Louis  Boursin)  /  188  pages  / 
Éditions  Montchrestien 
ISBN:  227511069 

Commentaire:  Bon  le  livre  est  intéressant,  car  il  donne  quelques  cas 
pratiques  basiques  et  quelques  idées.  Malheureusement,  sa  lecture  est 
indigeste  et  la  thématique  pas  très  bien  structurée  ni  orientée 
entreprise.  Je  lui  préfère  nettement  le  livre  sur  la  modélisation  du 
risque  et  simulation  de  Monte-Carlo  de  Hervé  Thiriez  qui  contient 
aussi  des  exemples  sur  la  théorie  des  jeux  mais  beaucoup  plus 
réalistes. 


Théorie  des  jeux  et  analyse  économique  (G.  Démangé,  J. -P. 
Ponssard)  /  233  pages  /  Éditions  Economie 


ISBN:  2130459730 
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Vincent  ISOZ 


Techniques  de  gestion  (F.  Hémici,  M.  Bounab)  /  234  pages  /  Éditions 
Dunod 

ISBN:  210003345X 

Commentaire:  C'est  l'ouvrage  avec  lequel  j'ai  commencé  dans  le 
domaine  de  la  gestion  de  projets,  car  il  est  utilisé  en  licence  dans  les 
Fac  de  France.  Il  est  orienté  calculs  uniquement  avec  très  peu 
d'explications,  mais  donne  quelques  bonnes  idées  à  appliquer  dans  le 
cadre  d'un  vrai  projet.  Il  est  complémentaire  aux  ouvrages  de 
statistiques  déjà  données  plus  haut. 


Éléments  de  mathématiques  appliquées  (Vincent  ISOZ)  /  ~4'900 
pages  /  Éditions  Sciences. ch  (gratuit  sur  le  web) 

ISBN:  978283999327 

Commentaire:  Mon  livre  sur  les  mathématiques  appliquées.  Il  n'est 
pas  encore  complet  et  contient  encore  quelques  coquilles,  mais  il  a 
l'avantage  de  contenir  quasiment  tous  les  sujets  techniques  que  le 
responsable  de  projet  de  niveau  Bac+5  en  logistique,  statistique, 
risques  et  qualité. 


Contrôle 

oc  ia  QUALITÉ 


Contrôle  de  la  qualité  -  MSP,  Analyse  des  performances,  Contrôle  de 
réception  (L.  Jaupi)  /  284  pages)  /  Éditions  Dunod 
ISBN:  2100042645 

Commentaire:  La  référence  mondiale  francophone  sur  le  sujet  selon 
moi.  Tellement  bon  et  précis  qu'il  est  toujours  dans  ma  bibliothèque  à 
portée  de  main  (alors  que  les  autres  ouvrages  que  j'ai  acheté  sur  le 
sujet  ont  tout  de  suite  passé  dans  des  magasins  de  seconde  main. . .). 
Cela  dit  le  niveau  de  lecture  requière  parfois  un  bac+3  pour 
comprendre  toutes  les  subtilités.  Un  petit  hic  cependant:  les 
démonstrations  mathématiques  détaillés  ne  sont  pas  disponibles  (ne 
serait-ce  qu'en  annexe)  et  il  y  a  quelques  petites  coquilles  mais 
facilement  identifiables  ! 


A  management  guide:  The  EF QM  Excellence  modelfor  assessing 
organizational  performance  (Chris  Hakes)  /  1 10  pages  /  Éditions  Van 
Haren 

ISBN:  9789087530273 

Commentaire:  J'avais  peur  de  m'ennuyer  en  lisant  ce  référentiel,  mais 
enfin  de  compte  j'ai  été  assez  agréablement  surpris  à  la  fin  de 
l'ouvrage.  Effectivement,  j'apprécie  beaucoup  l'initiative  d'un  système 
de  pondération  (notes)  permettant  de  juger  d'un  niveau  de 
performance  comparable  d'une  organisation  au  niveau  européen. 
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Statistique  chronologique  et  prévision  (Michel  Vate)  /  254  pages  / 
Éditions  Economica 


ISBN:  271782507X 


MÉTHODES  DE 
PREVISION 
A  COURT  TERME 


♦V 


Méthodes  de  prévision  à  court  terme  (Guy  Mélard)  /  537  pages  / 
Université  de  Bruxelles 
ISBN:  2800414081 


RISKand 

DECISION 

ANALYSIS 

in  Projects 


A  A 
A4  A  A 
kci  ▲  A 
A  Al  A 
AA  ▲ 


/?7,s7c  and  decision  analysis  in  project  (John  Schuyler)  /  259  pages  / 
Project  Management  Institute 
ISBN:  1880410281 

Commentaire:  Ce  livre  de  référence  pour  la  gestion  du  risque  dans  le 
cadre  du  PMBOK  est  critiqué  par  pas  mal  de  spécialiste  en 
modélisation  du  risque.  Je  pense  qu'ils  ont  mal  compris  l'objectif  de 
l'auteur  qui  est  de  faire  découvrir  les  concepts  et  non  pas  de  la 
maîtriser  (et  accessoirement  de  corriger  une  ancienne  erreur  du 
PMBOK).  Par  ailleurs,  le  sujet  est  très  complexe  et  nécessite  une 
maîtrise  en  mathématiques  et  un  coaching  présentiel  d'où  le  fait  que 
donner  des  exemples  pratiques  est  difficile  si  on  veut  tenter  de 
s'adresse  au  public  le  plus  large  possible.  Cela  reste  donc  une  bonne 
référence  pour  ceux  qui  confondent  le  domaine  élémentaire  qualitatif 
de  "l'identification  du  risque"  avec  le  domaine  quantitatif  de  haut 
niveau  qu'est  la  "modélisation  du  risque". 


Six  Sigma 
Statistics 

with  Excel 
and  Minitab 


Six  Sigma  Statistics  (Issa  Bass)  /  374  pages  /  Éditions  McGraw  Hill 
ISBN:  0071496467 

Commentaires:  Excellent  livre  en  anglais  orienté  pratique  sur  la 
partie  calculatoire  de  Six  Sigma  avec  le  non  moins  fameux  logiciel 
Minitab.  Le  livre  est  tellement  bon  en  termes  de  pédagogie,  de  clarté 
et  d'exemple  que  je  l'ai  encore  dans  ma  bibliothèque  de  nombreuses 
années  après  l'achat. 
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|i»*e$  Jours 


Statistiques  descriptives 
Exercices 


i 


Statistiques  descriptives  Exercices  (Pierre  Bailly,  Christine  Carrère)  / 
224  pages  /  Éditions  Libres-Cours 
ISBN:  9782706114120 

Commentaires:  Petit  ouvrage  pouvant  être  utile  aux  formateurs 
internes  d'entreprise  dont  les  collaborateurs  veulent  absolument  un 
support  papier.  Les  exercices  sont  pertinents. 


iean-Clautfe  GorfccJ 

MANAGEMENT  DE 

PROJET 


Management  de  projet  (Jean-Claude  Corbel)  /  169  pages  /  Éditions 

d'organisation 

ISBN:  2708128728 

Commentaire:  Bon  support  pour  connaître  quelques  outils 
intéressants  et  théoriques  de  la  gestion  de  projets.  Évidemment  on 
trouve  mieux  détaillé  et  gratuit  sur  le  web  mais  pour  ceux  qui  aiment 
le  papier  et  ne  savent  pas  ce  qu'il  faut  chercher  sur  Google  (ou  ne 
savent  tout  simplement  pas  chercher. . .)  cela  reste  un  excellent  début 
pour  connaître  le  nom  de  certaines  techniques  et  procédures 
empiriques. 


Data  Analysis  and  Business  Modeling  (Wayne  L.  Winsont)  /  598 
pages  /  Éditions  Microsoft  Press 
ISBN:  0-7356-2396-1 

Commentaire:  Comme  MS  Excel  reste  l'outil  le  plus  courant  soit  pour 
faire  des  statistiques,  analyses  ou  prévisions  ainsi  que  des  plannings 
pour  de  petits  projets  à  moins  de  20  millions  de  $  la  maîtrise  des 
techniques  avancées  de  cet  outil  est  indispensable.  Ce  dernier 
ouvrage  couvre  relativement  bien  les  connaissances  que  l'ont  fait  en 
MBA  dans  certaines  écoles.  Pour  les  scientifiques  et  ingénieurs  en 
gestion  de  projets  le  contenu  fera  plutôt  office  de  rappel  des  cours  de 
licence. 


Ultimate  Learning  Guide 


To  Microsoft  Office  Project  2007 


>Pn^ëetEiQçrt}. 


Ultimate  learning  Guide  to  Microsoft  Office  Project  2007  (Dale  A. 
Howard;  Gary  L.  Chefetz)  /  920  pages  /  Éditions  MSProjectExperts  / 
ISBN:  1934240001 

Commentaire:  Comme  tout  le  reste  des  ouvrages  de  la  même 
collection  que  ce  soit  pour  la  version  2007  ou  les  versions 
antérieures/ultérieures,  cet  ouvrage  est  un  must  pour  apprendre  ce 
logiciel! 
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Ingénierie  de  la  fiabilité  (P.  Lyonnet  )  /  323  pages  /  Éditions 
Lavoisier 

ISBN:  2743008237 

Commentaire:  L'ouvrage  ainsi  que  son  contenu  se  font  vieux. . .  même 
très  vieux  et  nécessiterait  une  bonne  réédition.  On  y  trouve  cependant 
quelques  informations  de  qualité,  mais  qu'il  faut  souvent  compléter 
par  de  la  littérature  se  trouvant  sur  des  sites  Internet.  J'ai  en  grande 
partie  récrit  l'ouvrage  dans  mon  propre  livre  de  mathématiques 
appliquées.  Cependant,  l'achat  peut  être  intéressant  sachant  que  c'est  à 
ma  connaissance  le  seul  livre  papier  en  français  à  ce  jour  sur  ce  sujet. 


Fundamentals  of  Forecasting  Using  Excel  (Kenneth  D.  Lawrence, 
Ronald  K.  Klimberg,  Sheila  M.  Lawrence)  /196  pages  /  Éditions  IP 
ISBN:  9780831133351 

Commentaire:  Excellent  ouvrage  pratique  sur  l'analyse  prévisionnelle 
pour  la  logistique,  la  gestion  et  la  planification.  Le  plus  c'est  le  CD- 
ROM  avec  les  fichiers  MS  Excel  qu'il  ne  reste  plus  qu'à  adapter  à  ses 
besoins.  Le  moins,  c'est  le  manque  de  rigueur  mathématique  et  de 
démonstrations  mais  il  faut  admettre  que  ce  n'est  pas  l'objectif  de 
l'ouvrage.  Le  lecteur  doit  donc  quand  même  faire  attention  à  être 
conseillé  judicieusement  par  un  spécialiste  dans  le  cadre  de  ses 
techniques  utilisées  dans  de  nombreuses  multinationales. 


Méthodes  de  gestion  de  projets  informatiques  /  Référentiel  Suisse  / 
-500  pages  cumulées  /  PDFs  gratuits 

Commentaire:  Un  peu  trop  théorique  et  idéaliste  à  mon  goût.  Reprend 
de  nombreux  concepts  d'ITIL  et  du  PMI  selon  mon  avis  personnel. 
L'intérêt  principal  est  qu'il  est  effectivement  vraiment  orienté  IT  avec 
le  vocabulaire  (pas  toujours  bien  choisi. . .)  et  des  processus  adaptés 
(seule  raison  pour  laquelle  je  fais  mention  de  cet  ouvrage  dans  la 
présente  liste).  Un  problème  cependant. . .  c'est  que  l'on  voit  qu'il  est 
orienté  principalement  déploiements  et  migrations  et  peu  (voir  pas  du 
tout. . .)  sur  les  développements  avec  les  contraintes  industrielles  de 
fiabilité  et  robustesse  statistiques  qui  y  sont  liées.  Une  trop  grosse 
part  fait  appel  à  des  approches  qualitatives  et  on  ne  peut  y  trouver 
aucune  technique  du  niveau  de  ce  dont  a  besoin  l'ingénieur  de  projets. 
Avantage  cependant  non  négligeable:  les  documents  sont  tous 
gratuits  et  disponibles  ici:  http://www.hermes.admin.ch 
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à  le  métier 

?  «  consultant 


i  fc'p' 


Le  métier  de  consultant:  Principes,  méthodes,  outils  (P.  Stern,  P. 
Tutoy)  /  286  pages  /  Éditions  Eyrolles 
ISBN:  9782708128996 

Commentaire:  Excellent  ouvrage  aussi  bien  pour  le  responsable  de 
projets  qui  souhaitent  apprendre  quelques  subtilités  avant  de 
mandater  des  consultants  externes  que  pour  ces  derniers  eux-mêmes. 
Un  bon  ouvrage  pour  la  culture  générale  à  avoir  lu  au  moins  une  fois! 


LE 
(  YGXE 
N’Olli 

Ni  Miik**ii  ■ 


L'approche 

processus 


Alain  COURTOIS 
Maurice  RILLET 


Mon* 

production 


Le  cygne  noir,  la  puissance  de  l'imprévisible  (N.  N.  Taleb)  / 

496  pages  /  Éditions  Les  Belles  Lettres 
ISBN:  978-2-251-44348-5 

Commentaire:  Sympathique  pour  la  culture  générale  mais  attention  à 
prendre  les  opinions  de  l’auteur  avec  des  pincettes,  car  vulgariser  les 
mathématiques  amène  l’auteur  des  exemples  aberrants  et  qui  peuvent 
être  considérés  par  le  lecteur  non  spécialiste  comme  une  preuve 
d’opinion. 


L'approche  processus  (H.  Brandenburg,  J.P.  Wojtyna)  /  191  pages  / 
Éditions  d'Organisation 
ISBN:  2708128884 

Commentaire:  Le  meilleur  ouvrage  en  français  que  j'ai  eu  entre  les 
mains  à  ce  jour  concernant  ISO  9001. 


Management  de  la  Qualité  (Frédéric  Canard)  /  257  pages  /  Éditions 
Gualino  lextenso 
ISBN:  9782297011112 

Commentaire:  Le  meilleur  ouvrage  en  français  que  j'ai  eu  entre  les 
mains  à  ce  jour  concernant  le  domaine  de  la  qualité  en  général.  Sans 
être  très  technique,  sans  proposer  des  documents  à  télécharger  sur 
Internet,  il  permet  d'acquérir  une  excellente  culture  générale  sur  le 
sujet. 


Gestion  de  production  (Alain  Courtois,  Maurice  Pillet,  Chantal 
Martin-Bonnefous)  /  457  pages  /  Éditions  d'Organisation  (Eyrolles) 
ISBN:  2708129864 

Commentaire:  Quelques  pages  intéressantes  mais  curieusement  c'est 
le  seul  ouvrage  parmi  ceux  déjà  cités  qui  aborde  de  façon  non 
exhaustive  des  techniques  quantitatives  fondamentales  (différents 
modèles  mathématiques  de  gestion  de  stocks,  organisation  des  flux, 
prévisionnel).  Cela  est  probablement  dû  à  l'intervention  de 
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Maurice  Pillet  en  tant  que  co-auteur... 


GHlt:Ten«au  -an-G  ,  Ahanda 


Guide  commenté 

des  normes 
et  référentiels 


À 


Guide  commenté  des  normes  et  référentiels  (Gilles  Teneau,  Jean-Guy 
Ahanda)  /  383  pages  /  Éditions  d'Organisation  (Eyrolles) 

ISBN:  978-2-212-54388-9 

Commentaire:  Très  bon  petit  ouvrage  listant  avec  quelques  descriptifs 
et  retour  d’expérience  des  normes,  référentiels,  méthodes  et  modèles 
majeures  de  l’industrie  et  de  l’administration.  Sympa  à  lire  et  on  en 
ressort  moins  ignorant. 


Statistical  Quality  Control  (Douglas  C.  Montgomery)  /  754  pages  / 
6th  Edition  (Wiley) 

ISBN:  978-0-470-16992-6 

Commentaire:  Montgomery  a  une  renommée  d’expert  international 
dans  le  domaine  de  la  qualité  et  ce  n’est  pas  pour  rien.  Son  ouvrage 
majeur  en  est  la  preuve  et  à  part  l’absence  de  démonstrations 
mathématiques  est  irréprochable. 


Optimisez  votre  plate-forme  logistique  (Michel  ROUX,  Tong  LIU)  / 
674  pages  /  4ème  Édition  (Eyrolles) 

ISBN:  978-2-212-54728-3 

Commentaire:  Superbe  ouvrage  très  pédagogique  et  ludique  sur  la 
gestion  de  la  plate-forme  logistique  (supply  chain).  Par  contre  au 
niveau  mathématique  passez  votre  chemin  il  n’y  a  aucune  technique 
de  niveaux  supérieur  au  BAC. 


La  gestion  des  opérations  (William  J.  Stevenson,  Claudio  Benedettit) 
/  819  pages  /  2ème  Édition  (Mc-Graw  Hill) 

ISBN:  2-7651-0406-9 

Commentaire:  Superbe  ouvrage  dans  la  même  trempe  que  la 
précédente  c'est-à-dire  très  pédagogique  et  ludique  sur  la  gestion  des 
opérations.  Par  contre  au  niveau  mathématique  le  niveau  est  supérieur 
à  celui  de  dessus  avec  quelques  démonstrations,  de  nombreux 
exemple  pratiques  numériques.  Une  référence  conseillée! 
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ISABELLE  NAZARE-AGA 

LES  MANIPULATEURS 
SONT  PARMI  NOUS 


H  4  | 

Rfjfifin 


What  every  engineer  should  know  about  decision  making  under 
uncertainty  (John  X.  Wang)  /  312  pages  /  Éditions  Marcel  Dekker 
ISBN:  0-8247-0808-3 

Commentaire:  Suite  à  la  demande  d'un  client  qui  voulait  un  livre 
papier  relié  plutôt  que  mon  livre  PDF  sur  les  techniques  relatives  aux 
techniques  décisionnelles  pour  ingénieurs  j'ai  du  lire  ce  livre  pour 
voir  le  niveau  de  son  contenu.  Donc  pour  résumer:  oui  c'est  le  seul 
livre  papier  et  relié  sur  ce  sujet  à  ma  connaissance  et  au  jour  où  j'écris 
ces  lignes  mais  les  sujets  traités  ne  décollent  pas  vraiment. . .  À  tous 
les  niveaux  mon  livre  électronique  est  bien  plus  complet  mais  c'est 
vrai  qu'il  est  en  français. . . 


Les  manipulateurs  sont  parmi  nous  (Isabelle  Mazare-Aga)  / 

286  pages  /  Éditions  de  l'Homme 
ISBN:  2-7619-1971-8 

Commentaire:  À  avoir  lu  au  moins  une  fois. ...  C'est  du  soft  skills  et 
donc  beaucoup  de  bon  sens  donc  pour  la  majorité  ce  nera  sera  qu'un 
catalogue  d'évidences  mais  c'est  toujours  sympa  à  lire  au  bord  du  lac 
un  jour  où  il  fait  beau. . . . 
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2.  Quelques  chiffres 

Attention!  !  !  Je  n'ai  pas  pu  vérifier  les  données  ci-dessous.  De  plus,  certains  termes  étant 
ambigus,  les  chiffres  associés  n'ont  alors  que  peu  de  valeur.  La  taille  des  échantillons 
statistiques  n'étant  pas  donnée,  il  n'est  aussi  pas  possible  de  déterminer  l'intervalle  de 
confiance  et  donc  la  variabilité  des  chiffres.  Bref,  il  faut  prendre  tous  ces  indicateurs  avec  des 
pincettes  puisque  leurs  auteurs  n'ont  pas  eu  la  rigueur  scientifique  de  bien  faire  leur  travail. . . 

Amélioration  des  résultats  financiers  induits  par  une  politique  d'entreprise  orientée  gestion  de 
projets  selon  enquête  du  Center  for  Business  Practices  ( www,  çbponline.  com )  : 

1.  Retour  sur  investissement:  -88% 

2.  Retour  sur  capital:  -25% 

3.  Valeur  économique  ajoutée:  -76% 

4.  Augmentation  des  ventes:  -34% 

5.  Amélioration  de  la  productivité:  -61% 

6.  Amélioration  en  matière  de  budget  de  fonctionnement:  -50% 

7.  Amélioration  en  matière  de  délais:  -50% 

8.  Amélioration  de  l'utilisation  des  ressources:  -50% 

9.  Amélioration  en  matière  de  délai  de  mise  sur  le  marché:  -43% 

10.  Amélioration  de  la  satisfaction  des  employés:  -36% 

Journal  "Le  Temps",  15  septembre  2004,  page  30,  annexe  "Le  Temps  Finance"  à  propos  du 
Taux  de  succès  des  projets  informatiques  bancaires : 

1.  20%  réussissent  (concept  de  " réussir "  non  défini  avec  exactitude  dans  le  journal) 

2.  35%  sont  retardés 

3.  45%  échouent  (concept  de  " échouer "  non  défini  avec  exactitude  dans  le  journal) 

The  Economist,  Spécial  Report,  27.  Nov.  2004 

1.  30%  des  projets  sont  arrêtés 

2.  50%  dépassent  le  budget 

3.  60%  sont  un  échec 

4.  90%  dépassent  les  délais 
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Dossier  "Gestion  de  projets",  LMI 28  mars  2005  (Source:  Standish  Group  2003) 

1.  44%  des  projets  sont  conformes  aux  prévisions  initiales 

2.  15%  d'échecs  purs  et  simples  dans  les  projets  informatiques 

3.  43%  des  projets  dépassent  les  coûts  prédéfinis 

4.  Les  projets  se  terminent  à  222%  de  la  durée  initialement  prévue  et  à  189%  des  coûts 
budgétés 

5.  70%  des  projets  ne  remplissent  pas  les  objectifs  fonctionnels  et  qualités 

6.  30%  des  projets  sont  abandonnés  avant  leur  terme. 

Étude  en  2009  du  Standish  Group  disponible  dans  leur  rapport  CHAOS: 

1.  33%  des  projets  sont  finis  à  temps,  dans  le  budget  et  avec  les  critères  exigés 

2.  24%  des  projets  sont  abandonnés  où  sont  un  échec  total 

3.  44%  des  projets  sont  soit  en  retard,  soient  hors  budget,  soit  ne  satisfont  pas  les  critères 
exigés 

Les  principales  causes  d'échec  sont: 

•  Changements  dans  les  priorités 

•  Objectifs  et  spécifications  non  clairement  définies 

•  Manque  de  ressources  dès  le  début  du  projet 

•  Délais  et  budgets  intenables  mais  acceptés  par  peur  de  dire  non 

•  Politique,  égoïsme,  existence  de  "chasses  gardées" 

•  Manque  d'expérience  en  gestion  de  projets  au  niveau  de  la  couche  supérieure  du 
management 

•  Déficiences  lors  de  la  phase  de  planification  du  projet  (non  maîtrise  des  outils 
contemporains) 

•  Mauvaises  communication  entre  le  projet  et  son  environnement 

•  Utilisation  de  techniques  de  management  de  niveau  seulement  BAC,  Licence  ou 
Master. 
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Pour  être  couronnés  de  succès,  on  remarque  très  vite  que  les  projets  nécessitent  l'existence  ou 
la  mise  en  place  de  différentes  conditions  à  leur  déroulement.  Parmi  ces  conditions,  citons: 

•  Le  soutien  écrit  absolu  et  non  ambigu  de  la  direction  avec  le  pouvoir  décisionnel  du 
responsable  de  projet  clairement  défini. 

•  Des  rôles  tenus  par  les  spécialistes,  les  meilleurs  et  les  plus  expérimentés  possible 
(ayant  si  possible  fait  des  cursus  de  plusieurs  années  en  ingénierie  de  gestion  de 
projets  ou  ayant  un  doctorat  dans  le  domaine).  Car  c'est  effectivement  par  le  manque 
de  compétences  techniques  en  gestion  de  projets  que  ceux-ci  sont  le  plus  souvent 
insatisfaisants. 

•  La  même  compréhension  par  le  donneur  d'ordre  et  la  direction  du  projet,  de  la  taille  de 
ce  dernier  et  des  principales  caractéristiques  déterminant  sont  type  et  sa  catégorie. 

•  Une  planification  réaliste  (probabiliste)  des  tâches  pouvant  être  maîtrisées  dans  le 
projet,  compte  tenu  des  limites  fixées  en  matière  de  temps,  d'argent,  de  quantité  et  de 
qualité. 

•  Une  grande  clarté  au  niveau  des  ressources  utilisables  et  des  éventuelles  restrictions 
concernant  leur  disponibilité  au  cours  du  projet. 

•  Une  réponse  positive  et  sûre  à  la  question  de  savoir  si  le  concept  de  projet  est  vraiment 
la  forme  d'exécution  appropriée  pour  atteindre  l'objectif  visé. 

•  L'utilisation  d'une  méthode  rationnelle,  adéquate  et  concluante  pour  le  traitement  de 
tous  les  résultats  correspondant  à  l'bojectif  du  projet.  C'est-à-dire  une  méthode  telle 
que  celle  proposée  par  le  PMI,  l'IPMA,  Prince2,  ISO  10006,  Hermès,  DMAIC  (Six 
Sigma),  PDCA,  etc. 
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YOUR  TEAM  UILL 
REPORT  TO  r\E  AND 
I  EL  TELL  THEM 
UHAT  TO  DO. 


WHO  UILL  REPORT 
TO  ME? 


I1L  NEED  TO 
APPROVE  ALL 
EYPENSES 


WHAT'S 

MY 

BUDGET?! 


IlL 
START 
ON  THE 
PROJECT 
PLAN 


HYPOTHCTICALLY, 
UJHO  UOULD  TARE 
THE  BLAME  IF  TH  IG 
PROJECT  FAILED? 


SMP  THAT  PART. 
I  ALREADY  HAVE 
A  PLAN  IN  MY 
HEAD. 


WELL. 

YOL^E 

IN 

CHARGE 


r  n 

YCU'LL  BE 

TN  CHARGE  OP 
THIS  PROJECT. 

Ceux  qui  le  peuvent  font  de  la  science,  les  autres...  de  la  méthodologie... 

J'ai  reprise  ici  un  article  dont  la  source  est: 

http://www.slate.fr/economie/80649/employes-managers-creatifs 

et  qui  permettra  à  des  nombreux  ingénieurs  très  compétents  techniquement  et  créatifs  de 
comprendre  pourquoi  être  un  bon  gestionnaire  (donc  métier  qui  qui  à  la  base  consiste  à  faire 
du  profit)  n'est  pas  très  compatible  avec  le  fait  d'être  un  bon  ingénieur  ou  scientifique  à  la 
base. 


[...]  Contrairement  à  l'idée  qui  a  encore  cours  dans  de  nombreuses  entreprises,  le  gestionnaire 
ne  doit  pas  être  créatif.  Evolv,  une  société  californienne  de  big  data  qui  travaille  à 
l'amélioration  des  performances  des  entreprises,  a  publié,  2013-12-01,  son  dernier  rapport 
trimestriel: 


http://go.evolvondemand.com/rs/evolvondemand/images/Q4  report  R2.pdf 

où  il  apparaît  que  les  gestionnaires  les  plus  créatifs  sont  aussi  ceux  qui  connaissent  le  turn¬ 
over  le  plus  important  dans  les  rangs  de  leurs  employés.  Plus  ces  derniers  sont  notés  par  leurs 
supérieurs  sur  une  échelle  d'innovation  et  de  créativité,  moins  ils  passent  de  temps  dans 
l'entreprise. 

Effectivement,  selon  Idris  Mootee,  PDG  du  cabinet  spécialisé  dans  l'innovation  stratégique 
Idea  Couture,  et  auteur  de  Design  Thinkingfor  Strategie  Innovation,  interrogé  par  le 
New  York  Times: 


«le  management,  c'est  avant  tout  s'assurer  de  l'exécution  de  tâches  répétitives  tout  en 
augmentant  la  productivité  des  machines  et  du  travail». 

Pas  grand-chose  à  voir,  donc,  avec  de  la  créativité.  Ni  même  avec  de  la  polyvalence:  un 
manager  capable  d'assumer  plusieurs  casquettes  garde  ses  employés  moins  longtemps  qu'un 
spécialiste. 

Selon  le  rapport  d 'Evolv,  les  principales  qualités  d'un  bon  gestionnaire  sont  la  pédagogie,  le 
leadership  et  l'adaptabilité:  au  lieu  d'établir  des  stratégies  et  des  plans  pour  les  temps  à  venir, 
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il  est  plus  rentable,  en  terme  de  conservation  des  salariés,  de  s'adapter  aux  changements  au 
jour  le  jour.  Toujours  selon  ce  rapport,  les  managers  les  plus  organisés,  et  donc  leurs 
subordonnés,  ne  sont  pas  aussi  performants  que  les  plus  communicatifs.  [...] 
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3.  Erreurs... 


C'est  impossible,  dit  la  Fierté,  C'est  risqué,  dit  l'Expérience,  C'est  sans  issue,  dit  la  Raison  Essayons,  murmure  le  Cœur 

William  Arthur  Ward 

Après  avoir  lu  plus  d'une  centaine  de  livres  et  de  documents  de  tous  types  sur  la  gestion  de 
projets,  la  logistique,  la  finance,  la  qualité,  les  risques,  le  leadership. . .  du  niveau  Bac  au 
niveau  Bac+7  je  constate  qu'aucun  auteur  ne  partage  les  erreurs  vécues  dans  le  cadre  de  ses 
propres  projets  ou  de  ceux  où  il  a  accompagné  des  clients  et  ce  de  manière  relativement 
détaillée.  Or,  je  pense  que  c'est  surtout  cela  qui  intéresserait  les  responsables  de  projets 
débutants.  Donc  voici  la  liste  des  erreurs  vécues  en  tant  que  responsable  et  consultant  en 
gestion  de  projets  dans  l'ordre  des  plus  fréquents  et  qui  peut  être  résumée  naïvement  par  les 
quatre  fondamentaux  structurels  du  Contribution  Framework. 


de  la  confusion  de  l'indifférence  des  carences  de  la  négligence 

(®> 

q 

b 

O 

où  simplement  il  est  indiqué  (trivial)  que  l'échec  d'un  projet  est  toujours  dû  à  la  présence  de 
confusion,  d'indifférence,  de  carences  et  de  négligences. 
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Voici  quelques  causes  fréquentes  d'erreurs  (l'ordre  est  complètement  arbitraire): 


Cause  du  problème 

Effet 

Aucun  support  de  la  direction 

Les  méthodes  de  gestion,  outils  et  directives 
associées  ne  sont  pas  imposées  à  l'ensemble 
des  employés,  ce  qui  génère  un  chaos  quasi 
total  et  une  énorme  perte  de  temps  et 
d'argent  ainsi  que  des  conflits. 

Manque  des  ressources,  absence  de  réserve 
financière 

Le  cause  est  connue  de  tous  donc  pas  besoin 
de  l'expliciter  je  pense. . . 

Mauvais  outils 

Les  outils  de  gestion  ne  sont  pas  les  bons 
(gestion  documentaire  avec  un  disque 
réseau,  plannings  faits  dans  un  tableur, 
communication  par  courriel,  bref 
catastrophe  connue  d'avance). 

Formation  et  expérience  insuffisante  des 
intervenants 

La  grande  majorité  des  responsables  de 
projets  ont  un  niveau  intellectuel  et  de 
rigueur  insuffisants  pour  gérer  et  évaluer 
correctement  un  projet.  Donc,  les  coûts,  la 
qualité  et  les  délais  sont  très  mal  évalués. 

Comportement  réactif  des  acteurs  du  projet 

La  majorité  des  acteurs  du  projet  travaillent 
dans  un  mode  réactif  (ne  rien  faire  jusqu'à  ce 
qu'un  facteur  externe  oblige  à  réagir)  alors 
qu'il  faut  avoir  un  comportement  proactif 
(tout  le  temps  en  recherche  d'amélioration  de 
l'existant  au-delà  de  ce  qui  est  nécessaire). 

Pas  de  légitimité 

La  direction  montre  devant  les  ressources  du 
projet  qu'elle  ne  fait  pas  confiance  à  son 
responsable  de  projet  et  l'infantilise.  Le 
responsable  est  alors  décrédibilisé  et  les 
ressources  ne  prennent  pas  compte  de  ses 
directives  et  le  projet  échoue  à  tenir  ses 
objectifs 

Compétences 

Le  mandataire  n'a  pas  les  compétences  pour 
exécuter  le  projet  mais  l'accepte  quand 
même  ce  qui  produit  souvent  des  explosions 
de  coûts  et  délais.  À  noter  que  parfois 
l'inverse  se  produit:  le  mandataire  et  trop 
compétent  et  donc  demande  trop  de  détails 
aux  clients  ou  est  trop  exigeant  envers  ce 
dernier  ce  qui  provoque  des  tensions. 

Pas  de  procès-verbal  des  réunions,  conflits 
ou  autres 

Aucune  traçabilité  des  promesses  ou 
objectifs  ce  qui  génère  encore  plus  de  conflit 

Ingénierie  de  Gestion  de  projets 


38/547 


Vincent  ISOZ 


Cause  du  problème 

Effet 

et  de  chaos  dans  le  projet. 

Terminologie  non  rigoureusement  définie, 
discours  vague. 

Les  requêtes  et  explications  ne  sont  pas 
claires  car  ni  le  client,  ni  le  manager  n'ont  un 
discours  rigoureux  et  ne  définissent 
correctement  les  mots  qu'ils  utilisent  n'y  ne 
posent  les  hypothèse  de  fonctionnement. 
Conséquences:  mauvaises  interprétations, 
travail  incorrect,  problèmes  de 
communication. 

Mauvaise  implication  des  ressources 

Certains  responsables  de  projets  font  croire  à 
leurs  ressources  qu'ils  les  impliquent  dans  un 
projet  en  leur  demandant  leur  avis  pour  finir 
par  imposer  finalement  toujours  le  leur  en 
faisant  de  la  négociation  par  bout  de 
chandelle. . . 

Réunions  périodiques  avec  le  client  non 
planifiées 

Les  projets  n'ont  souvent  pas  de  cahier  des 
charges  en  interne  et  donc  de  nouvelles 
attentes  apparaissent  lors  de  l'avancement  du 
projet  que  le  mandataire  (prestataire)  n'avait 
pas  exprimé  correctement  au  début.  Des 
réunions  régulières  où  l'on  présente 
l'avancement  du  livrable  permettraient  d'y 
remédier. 

Peur  de  demander  au  client  un  cahier  des 
charges  détaillé 

Des  imprévus  arrivent  constamment  pendant 
la  réalisation  du  projet  car  le  client  n'ayant 
pas  réfléchi  avant  il  change  ses  exigences  en 
cours  de  route.  Cela  a  pour  effet  d'exploser 
les  délais  et  les  coûts  du  projet  et  d'énerver 
les  ressources  ainsi  que  les  responsables  du 
projet. 

Pas  de  standard  de  management  mis  en 
place 

Un  peu  plus  de  99%  des  organisations 
utilisent  la  méthode  La  Rache  pour  gérer 
leurs  projets.  Donc  le  livrable  ainsi  que 
l'ambiance  au  sein  de  l'organisation  sont  à 
l'image  de  cette  méthode. . . 

Pas  de  scénarios  créés 

La  quasi-totalité  des  responsables  de  projets 
ne  savent  pas  qu'il  faut  faire  au  moins  3 
voire  4  scénarios  d'un  projet,  voire  au  mieux 
une  simulation  de  Monte-Carlo  ou  par 
Bootstrapping  avec  une  probabilité  cumulée 
à  95%  au  moins.  Dans  le  cas  contraire,  nous 
nous  retrouvons  alors  avec  des  objectifs  qui 
n'ont  qu'une  chance  sur  deux  d'être  respectés 
et  des  réponses  à  appel  d'offre  (et  les  forfaits 
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Cause  du  problème 

Effet 

associés)  qui  n'ont  aucune  rigueur. 

Oubli  des  absences  des  ressources  et  du 
temps  de  travail  effectif 

Le  responsable  de  projet  prend  plusieurs 
mois  de  retard  dans  son  projet  (et  les  coûts 
qui  vont  avec)  car  il  a  oublié  d'intégrer  les 
vacances,  les  jours  de  congé  maladie,  jours 
de  congé  enterrement  familial,  jours  de 
congés  maladie  des  enfants,  le  service 
militaire,  les  congés  maternité  éventuels  ou 
encore  l'impossibilité  d'avoir  un  taux  effectif 
à  100%  de  ses  ressources  dans  le  projet. . . 

Mauvais  outils  utilisés 

La  grande  majorité  des  organisations 
utilisent  un  tableau  pour  gérer  un  projet  ou 
un  planning.  C'est  bien  évidemment  une 
grave  erreur  qui  ne  souffre  d'aucune  excuse 
puisqu'il  existe  des  logiciels  de  gestion  de 
projets  gratuits.  L'utilisation  des  tableurs 
engendre  des  erreurs  de  calculs,  des 
problèmes  de  mise  à  jour  et  un  suivi 
impossible  des  ressources  de  manière 
satisfaisant  et  ne  respecte  surtout  aucun 
standard. 

Mauvaise  communication  et  outils  de 
communication 

Les  différents  médias  de  communications  ne 
sont  pas  centralisés  dans  un  pot  commun. 
Donc,  chaque  intervenant  a  des  infos  dont  il 
fait  une  rétention  involontaire  qui  peut 
amener  à  des  graves  anomalies  avec  le 
mandant  (soumissionnaire)  et  le  mandataire 
(prestataire). 

Temps  insuffisant  réservé  pour  le  suivi,  la 
préparation,  les  réunions,  la  gestion  des 
conflits,  la  documentation.... 

Erreurs  multiples  dans  l'estimation  des 
durées,  des  coûts,  des  ressources,  dans  la 
communication  avec  le  client  et  la  qualité. 
Documentation,  cahier  des  charges  non 
effectués  donc  aucun  suivi  possible  à  long 
terme.  Pas  de  réunions  planifiables  pour 
faire  le  point  sur  les  jalons  (inexistants  de 
toute  manière. . .).  Donc  le  projet  va  au 
fiasco! 

Les  commerciaux  ont  vendu  une  durée  de 
projet  sans  avoir  demandé  au  responsable  de 
projet  et  exécutant  au  préalable  sur  la 
faisabilité. 

Conflits  internes  dus  au  non-respect  des 
processus  et  formation  des  commerciaux 
insuffisante  relativement  à  leur  esprit 
d'analyse  et  leur  honnêteté  vis-à-vis  du 
client. 

Compétences  des  ressources  non  vérifiées 

Travail  bâclé  ou  ne  correspondant  pas  au 
livrable  attendu.  Il  peut  arriver  qu'il  faille 
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Cause  du  problème 

Effet 

toute  refaire. 

Pas  de  backup  des  ressources  ou  de 
maintenance  préventive  (AMDEC) 

Une  ressource  indispensable  est  absente  et 
bloque  tout  le  projet.  Une  machine  tombe  en 
panne  et  il  n'y  a  rien  de  prévu  pour  la 
remplacer  ce  qui  engendre  des  coûts 
considérables  et  une  image  qu'il  sera  très 
difficile  à  relever. 

Le  client  effectue  des  manipulations  sur  le 
produit  qui  ne  font  pas  partie  du  cahier  des 
charges  initial. 

Le  client  accuse  à  tort  le  fournisseur.  Au 
fait,  il  ne  faut  jamais  oublier  de  former  les 
utilisateurs  au  produit  final  quel  qu'il  soit! 

Le  responsable  de  projet  a  un  Master  alors 
s'estime  bon. 

Au  fait  ils  sont  aussi  mauvais  que  les  autres. 
Un  responsable  de  projet  de  haut  niveau  doit 
posséder  un  doctorat  ou  l'équivalent  d'un 
bac+7  dans  un  domaine  des  sciences  exactes 
avec  au  moins  10  années  d'expérience  dans 
une  organisation  en  tant  qu'employé  normal 
avant  de  devenir  responsable  de  projet. 

Dans  l'idéal,  il  faut  faire  passer  un  test  de 
logique,  de  capacité  d'analyse  et  de 
raisonnement  à  tout  responsable  de  projet. 

Le  niveau  de  délégation  (pouvoir 
décisionnel)  n'a  pas  été  clairement  défini. 

Cela  peut  amener  le  responsable  de  projet  à 
prendre  des  décisions  qui  seront  par  la  suite 
rejetées  par  la  direction  qui  souhaitait  au  fait 
implicitement  une  validation. 

L'organisation  interne  s'autoproclame 
comme  satisfaisante  voire  excellente 

En  réalité  c'est  souvent  le  chaos  et  les 
instances  dirigeantes  ne  connaissent  pas  les 
certifications  ISO  ou  des  méthodes 
d'appréciation  comme  EFQM.  Après  en 
avoir  pris  connaissance  ils  tombent  de  très 
haut... 

Pas  de  culture  de  gestion  de  projets  au  sein 
d'une  grande  entreprise  et  pas  d'employé(s) 
dédié(s)  uniquement  à  cette  tâche 
spécialisée. 

La  gestion  se  fait  à  l'arrache  et  ils  n'ont 
jamais  lu  d'ouvrage  complet  sur  le  sujet 
(comme  celui  que  vous  êtes  en  train  de  lire 
par  exemple). 

Tableau  1  Erreurs  rencontrées 
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4.  N.R.M.M 


Les  N.R.M.M.  (Normes,  Référentiels,  Méthodes  et  Modèles)  de  gestion  de  projets  existent 
depuis  environ  le  début  des  années  1950.  Les  normes  sont  des  exigences  alors  que  les 
référentiels  sont  des  recommandations.  Les  méthodes  et  les  modèles  sont  des  outils  qui 
servent  aux  référentiels  ou  aux  normes  dans  le  cadre  du  Système  de  Management  de  la 
Qualité  de  la  Sécurité  et  de  l'Environnement  (S.M.Q.S.E.), 

Certaines  mauvaises  langues  (qui  n'ont  pas  vraiment  tord  sur  le  fond...)  disent  que  les  normes 
sont  des  outils  mis  en  place  par  de  gros  groupes  industriels  pour  empêcher  des  petites  PME 
innovantes  de  pouvoir  les  concurrencer  (sachant  que  le  respect  de  certaines  normes 
nécessitent  des  investissements  financiers  considérables).  De  même  d'autres  disent  aussi  (et  ils 
n'ont  pas  vraiment  tord  non  plus  dans  certains  cas...)  que  les  standards  et  les  normes  sont  des 
outils  mis  en  place  par  les  gouvernements  pour  créer  artificiellement  de  l'emploi  administratif 
dans  un  monde  surpeuplé... 

Par  exemple,  la  méthode  P.D.C.A.  est  utilisée  par  des  nombreuses  normes  et  référentiels.  Les 
modèles  sont  quant  à  eux  des  outils  simples  tandis  que  les  méthodes  sont  souvent  plus 
complexes.  Certaines  méthodes  se  suffisent  à  elles-mêmes,  c'est  le  cas  pour  Six  Sigma. 


0 


CLIENTS  ET  FOURNISSEURS 


DIRECTION  DE  L'ENTREPRISE 

□ 


0 

0 


NORMES 


RÉFÉRENTIEL 


MÉTHODES 


MODÈLES 


Le  personnel 

I  ^  I  Femmes  et  hommes 

*  de  l'entreprise 


Marché  économique  national  et  international 


Il  est  cependant  regrettable  de  constater  que  c'est  malheureusement  devenu  principalement  un 
business  très  lucratif  en  termes  de  formations,  de  certifications  et  de  débouchés  commerciaux 
(Consulting  sur  mandats,  produits  dérivés,  livres,  etc.)  vendus  comme  des  solutions  quasi 
miraculeuses  à  tous  les  problèmes.  Leur  nombre  est  aussi  devenu  un  problème  comme  en 
atteste  la  cartographie  ci-dessous  pour  les  normes  et  référentiels: 
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LÉGENDE 


Normes 


Figure  1  Cartographie  normes  et  référentiels  (source  ISBN  978-2-212-54388-9) 

et  pour  les  méthodes  et  modèles: 
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Figure  2  Cartographie  méthodes  et  modèles  (source  ISBN  978-2-212-54388-9) 

La  quasi  totalité  des  N.R.M.M.  sont  triviales  à  apprendre  (niveau  Bac  et  encore...)  et  ne 
nécessitent  pas  obligatoirement  de  formations  (un  bon  livre  suffit).  La  difficulté  réside  dans 
leur  mise  en  place  à  cause  de  l'inertie  de  l'environnement  dans  lequel  se  trouve  le  responsable 
de  projets  (souvent  pas  absence  d'appui  de  la  direction  au  plus  haut  niveau). 


NRMM 

Définition 

Exemples 

Norme 

Document  de  référence  sur  un  sujet  ou  un 
domaine  donné  en  accord  avec  la 
réglementation  nationale  (norme  suisse, 
européenne  ou  internationale). 

Certification  de  l'entreprise  obligatoire 
dans  bien  des  cas  mais  audits 
malheureusement  pas  indépendants. 

ISO  9001:2000,  ISO 
14001:2004,  ISO/IEC 

27001,  SA  8000,  ISO  31000, 
etc. 

Référentiel 

Standard  ("best  practice"  du  métier...) 
reconnu  par  des  professionnels  du  domaine 
et  qui  se  réfère  souvent  à  une  norme. 
Certification  des  personnes  dans  bien  des 
cas. 

ITIL  V2/V3,  COBIT, 

CMMi,  IPMA;  PMI, 
Zachmann,  etc. 

Méthode 

Ensemble  des  démarches  formalisées  selon 
des  principes,  dans  le  but  d'acquérir  un 
savoir-faire  conforme  aux  objectifs 
attendus.  Utilisation  de  la  méthode  à 
travers  l'entreprise  ou  une  partie  de 

AMDEC,  BSC,  Kaizen, 

Six  Sigma,  etc. 
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l'entreprise. 

Modèle 

Outil  qui,  grâce  à  ses  caractéristiques,  ses 
qualités,  son  utilisation,  peut  servir  de 
référence  à  l'imitation  ou  à  la  reproduction. 
Application  du  modèle  pour  un  domaine 
ou  une  activité  de  l'entreprise 

Ishikawa,  Pareto,  Chaîne  de 
la  valeur,  5S,  8S,  5P, 

SWOT,  etc. 

Tableau  2  NRMM 


Le  praticien  professionnel  ne  doit  lui  jamais  oublier  que  des  "standards"  sont  bien 
évidemment  rarement  adaptés  totalement  à  leurs  cas  pratiques  réels  exceptés  s'ils  sont 
imposés  par  des  normes  nationales  ou  internationales. . .  (en  France,  en  2001,  sur  plus  de 
21'000  normes,  seulement  et  malheureusement...  240  sont  obligatoires). 


Il  faut  voir  les  méthodologies  et  standards  à  la  mode  plutôt  comme  des  best  practices 
(meilleures  pratiques2/best  practices)  fonctionnant  relativement  bien  et  permettant  d'éviter  des 
erreurs  triviales  qu'il  faut  démonter  pour  créer  son  propre  standard  adapté  à  ses  besoins  et  aux 
contraintes  de  son  entreprise:  avoir  une  bonne  méthode  de  management  standardisée  et  testée 
constitue  aussi  la  base  d'une  bonne  gestion  de  projets  (tout  en  évitant  "l'obstruction 
méthodologique")!  C'est  par  ailleurs  ainsi  que  de  nombreuses  méthodes  connues 
mondialement  ont  vu  le  jour! 


2  Encore  faudrait-il  définir  mathématiquement  cette  notion  de  "bonne  pratique"  ce  qui  est  facilement  possible 
mais  dépasse  le  contexte  de  cet  ouvrage. 
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Nous  nous  proposons  ici  de  donner  une  liste  non  exhaustive  (dans  l'ordre  qui  semble  à  priori 
des  plus  connus)  avec  une  brève  description  des  formations  et  méthodes  que  nous  avons 
rencontrées  dans  le  cadre  de  nos  expertises  dans  le  management. 

Nous  pouvons  dire  que  chacune  de  ces  méthodes  respecte  une  approche  conforme  aux  7S 
mais  en  mettant  l'accent  plus  sur  certains  points  que  d'autres: 

•  La  stratégie  (strategy) 

•  La  structure  (structure) 

•  Le  système  (système) 

•  Le  style  de  management  (style) 

•  Les  ressources  humaines  (staff) 

•  Le  savoir-faire  (skills) 

•  Les  valeurs  partagées  (shared  values) 

Enfin,  rappelons  que  selon  le  BABOK,  le  business  analyst  et  donc  aussi  un  peu  le 
coordinateur  de  projets  devraient  choisir  les  méthodes  et  outils  de  gestion  en  fonction  de  la 
disponibilité  des  outils,  de  leurs  limitations,  des  standards  organisationnels,  des  contraintes 
temporelles  et  du  budget. 


4.1  IREB 


International 

Requirements 

Engineering 

Board 


I 


En  ingénierie,  et  plus  particulièrement  dans  les  procédures  d'appel  d'offres,  les  exigences  sont 
l'expression  d'un  besoin  documenté  sur  ce  qu'un  produit  ou  un  service  particulier  devrait  être 
ou  faire. 

Dans  l'approche  classique  de  l'ingénierie,  les  exigences  sont  bien  évidemment  considérées 
comme  des  prérequis  pour  les  étapes  de  conception  et  de  développement. 

Le  coût  de  correction  des  erreurs  de  spécification  augmente  bien  évidemment  avec  le  délai  de 
détection  et  les  erreurs  de  spécification  sont  souvent  découvertes  très  tard  ou  après  la  mise  en 
production. 

L'ingénierie  des  exigences  a  un  impact  significatif  sur  la  réussite  du  projet.  Elle  délimite 
l'étendue  du  projet  et  établit  une  base  de  communication  commune  à  toutes  les  parties 
impliquées  dans  un  projet.  La  maîtrise  de  la  définition  des  exigences  aboutit  à  des  solutions 
conformes  aux  besoins  et  permet  ainsi  une  diminution  des  coûts  et  des  risques  d'échec. 
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L'IREB  a  établi  un  cadre  professionnel  de  pratiques  et  de  savoir-faire  dans  le  domaine  de 
l'ingénierie  des  exigences  qui  assure: 

•  Une  compréhension  commune  de  l'ingénierie  des  exigences  au  sein  d'une  entreprise  et 
entre  les  parties  prenantes  aboutissant  ainsi  à  une  communication  beaucoup  plus 
efficace;  on  sait  de  quoi  on  parle 

•  Une  augmentation  de  la  qualité  des  livrables  des  projets  par  la  définition  des  exigences 
basée  sur  un  modèle  éprouvé  et  compris 

•  Une  réduction  des  coûts  de  développement  et  un  respect  des  délais 

•  Une  meilleure  transparence  sur  les  compétences  des  ingénieurs  et  les  analystes 
business  exerçant  dans  le  domaine  de  la  définition  des  exigences.  Le  niveau  de 
certification  donne  une  description  précise  des  compétences  requises  par  un  poste  de 
travail  et  du  degré  de  compétences  d'une  personne. 

Formation:  ~4  jours 
Niveau:  Bac 

Source:  www.ireb.org 
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4.2  ISO  10006:2003 


Organisation 
internationale  de 
normalisation 


L'ISO  10006:2003  donne  des  conseils  sur  l'application  du  management  de  la  qualité  aux 


projets.  Elle  est  applicable  à  des  projets  de  complexité  variable,  qu'ils  soient  petits  ou  grands, 
de  courte  ou  longue  durée,  qui  se  situent  dans  des  environnements  différents,  quel  que  soit  le 
type  de  produit  ou  de  processus  de  projet.  Il  peut  être  bien  évidemment  nécessaire  d'adapter 
ces  conseils  à  un  projet  précis. 

Ce  standard  ne  constitue  cependant  pas  un  guide  pour  le  management  de  projet  en  lui-même, 
mais  se  contente  de  donner  des  conseils  sur  la  qualité  dans  le  cadre  des  processus  de 
management  de  projet  alors  que  l'ISO  9004  donne  des  conseils  sur  la  qualité  dans  le  cadre  des 
processus  relatifs  au  produit  du  projet  et  sur  l'approche  processus. 

Il  convient  de  noter  que  le  présent  standard  international  est  un  recueil  de  conseils  et  qu'elle 
n'est  pas  destinée  à  être  utilisée  pour  des  besoins  de  certification/enregistrement. 

Formation:  ~1  jour  par  code  ISO 
Niveau:  Bac 
Source:  wwwjsççarg. 

Remarque :  Personnellement,  j'utilise  le  plus  possible  dans  mes  projets  les  standards  suivants 
(j'ai  listé  car  on  me  le  demande  relativement  souvent  dans  mes  cours): 

•  ISO-8859-1:  Pour  les  caractères  utilisés  dans  les  noms  de  fichiers  et  pour  les  dossiers 
électroniques 

•  ISO  9660  (niveau  Bac):  Servant  de  base  pour  les  règles  de  nommage  des  fichiers  et 
dossiers  de  projets  qui  nécessitent  un  travail  multiplateforme  et  avec  une  comptabilité 
sur  tout  système  informatique  (malheureusement  peu  respecté  en  toute  rigueur!). 

Ainsi,  il  est  d'usage  d'essayer  de  respecter  au  mieux  les  règles  suivantes  dans  les 
projets  en  ce  début  de  21ème  siècle: 

-  Un  seul  séparant  le  nom  de  l'extension  et  aucun  point  dans  les  noms  de  dossiers 

-  Les  dossiers  sont  en  majuscules  et  ne  comportent  eux  aucun  point 

-  Les  fichiers  auront  une  majuscule  pour  la  première  lettre  de  chaque  mot,  le  reste 
étant  en  minuscule 

-  L'extension  peut  être  sur  1  à  4  caractères  et  toujours  en  minuscules 

-  Maximum  106  caractères  pour  les  noms  de  fichiers  (y  compris  extension)  ou  dossiers 

-  Les  noms  ne  doivent  pas  commencer  par  un  chiffre 

-  Les  espaces  seront  remplacés  par  des  "underscores"  (mais  on  peut  les  remplacer  les 
underscores  la  majorité  du  temps  par  l'obligation  de  commencer  chaque  terme  dans  le 
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nom  des  fichiers  avec  une  majuscule,  le  reste  étant  en  minuscule) 

-  Il  ne  devrait  pas  y  avoir  d'accents  dans  les  noms  de  fichiers 

-  Les  caractères  suivants  sont  proscrits:  ?!#+"%&A()=][$€{}-;:*><,'~l@°£ 

Remarque:  Si  nous  rajoutons  ISO  9001  aux  noms  de  fichiers,  ceux-ci  peuvent  dans 
certains  cas  comporter  dans  le  nom  du  fichier  l'abréviation  de  la  langue  du  contenu  sur 
deux  lettres  (FR,  EN,  DE,  . . .),  l'identifiant  unique  au  début  du  nom  de  fichier  (IDC1, 
IDP1,  IDR1,. . .)  et  juste  avant  le  point  séparant  le  nom  de  l'extension,  le  numéro  de  la 
version  majeure  (VI,  V2,  V3,. . .)  avec  l'indication  de  la  version  mineure  séparée  par 
un  underscore  (Vl_3,  V3_4)  et  enfin  avec  le  numéro  de  révision  (Vl_3rl4,  Vl_0r3). 

Il  y  a  donc  au  minimum  déjà  12  caractères  sur  les  26  pris  rien  que  pour  avoir  une  règle 
de  nommage  normalisée  correcte.  Enfin,  pour  les  dossiers,  il  est  déconseillé  d'avoir 
plus  de  8  niveaux  imbriqués. 

•  ISO  216  (niveau  Bac):  Pour  les  formats  de  papier  (bon  ça  c'est  facile  mais  j'ai  déjà  vu 
des  entreprises  qui  avaient  des  responsables  de  projets  travaillent  avec  des  formats  de 
papier  exotique  par  manque  de  maîtrise  des  logiciels  de  traitement  de  texte) 

•  ISO  690  (niveau  Bac):  Pour  les  cartouches  au  début  de  chaque  document  important 
(indiquant  l'auteur,  le  responsable,  la  version,  le  référentiel,  le  niveau  de 
confidentialité,  l'année,  l'identificateur,  etc.).  Certains  des  documents  électroniques 
fournis  pendant  le  cours  ont  une  cartouche  conforme  ISO  690  pour  être  par  la  suite 
référencés  correctement.  Plusieurs  méthodes  de  gestion  de  projets  recommandent 
implicitement  de  suivre  cette  norme. 

•  ISO  639.2  (niveau  Bac):  Pour  les  métadonnées  concernant  l'identification  des  langues 
de  documents. 

•  ISO  4217  (niveau  Bac):  Pour  respecter  les  symboles  des  formats  monétaires  dans  mes 
offres  et  dans  les  logiciels  de  simulation. 

•  ISO  5807  (niveau  Bac  à  Bac+5):  Pour  schématiser  et  documenter  des  processus 
(logigrammes).  Parfois  je  dévie  cependant  sur  du  BPMN  (Business  Process 
Management)  ou  de  l'AdP  (Arbre  de  défaillance  Probabilistes)  que  je  présenterai 
sommairement  plus  loin  dans  le  document. 

Pour  avoir  plus  de  détails,  il  suffit  d'acheter  le  PDF  sur  le  site  internet  ISO.org  ou  de 
suivre  mon  cours  sur  le  sujet  (la  première  option  étant  plus  simple  et  moins  onéreuse). 

•  ISO  9001  (niveau  Bac  à  Bac+1):  Pour  tout  ce  qui  a  trait  à  la  qualité  sous  forme 
généraliste  (série  de  normes  ISO  9000). 

Pour  avoir  plus  de  détails,  il  suffit  d'acheter  le  PDF  sur  le  site  internet  ISO.org  ou  de 
suivre  un  cours  sur  le  sujet  (la  première  option  étant  plus  simple,  moins  onéreuse  et 
plus  rigoureuse).  De  toute  façon  même  si  vous  suivez  une  formation  ISO  9001  vous 
devrez  obligatoirement  acheter  et  lire  le  PDF.  Indiquons  que  la  norme  ISO  9001 
regroupe  les  normes  ISO  9001,  9002  et  9003  qui  existaient  en  1994. 
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•  Norme  AFNOR  NF  Z  12.001  (niveau  Bac):  Pour  tout  ce  qui  est  relatif  aux 
organigrammes  puisqu'il  n'existe  pas  à  ma  connaissance  (malheureusement!)  de 
standard  ISO  pour  cela. 

La  documentation  à  ce  sujet  disponible  sur  Internet  à  ce  jour  est  suffisante. 

•  ISO  3951  (niveau  Bac+3  à  Bac+5):  Pour  tout  ce  qui  est  relatif  aux  contrôles  de 
réception  de  lots  ou  aux  contrats  incluant  des  clauses  de  qualité  basées  sur  des  plans 
d'échantillonnages  aux  mesures.  Cependant,  je  lui  préfère  son  équivalent  français 
qu'est  l' AFNOR  X06-023. 

Pour  avoir  plus  de  détails,  il  suffit  d'acheter  le  PDF  sur  le  site  internet  ISO.org  ou  de 
suivre  un  cours  sur  le  sujet  (la  première  option  étant  plus  simple  et  moins  onéreuse). 
De  toute  façon  même  si  vous  suivez  une  formation  sur  le  sujet,  vous  devrez 
obligatoirement  acheter  et  lire  le  PDF.  Vous  trouverez  sur  Internet  aussi  une  large 
documentation  que  j'ai  écrite  avec  presque  toutes  les  démonstrations  mathématiques  à 
ce  sujet. 

•  ISO  2859  (niveau  Bac+3  à  Bac+5):  Pour  tout  ce  qui  est  relatif  aux  contrôles  de 
réception  de  lots  ou  aux  contrats  incluant  des  clauses  de  qualité  basées  sur  des  plans 
d'échantillonnages  aux  attributs.  Cependant,  je  lui  préfère  son  équivalent  français 
qu'est  l'AFNORX06-023. 

Pour  avoir  plus  de  détails,  il  suffit  d'acheter  le  PDF  sur  le  site  internet  ISO.org  ou  de 
suivre  un  cours  sur  le  sujet  (la  première  option  étant  plus  simple  et  moins).  De  toute 
façon  même  si  vous  suivez  une  formation  sur  le  sujet  vous  devrez  obligatoirement 
acheter  et  lire  le  PDF.  Vous  trouverez  sur  Internet  aussi  une  large  documentation  que 
j'ai  écrite  avec  presque  toutes  les  démonstrations  mathématiques  à  ce  sujet. 

•  ISO  8258  (niveau  Bac+3  à  Bac+5):  Pour  tout  ce  qui  est  relatif  aux  cartes  de  contrôles 
les  plus  communes  dans  le  domaine  la  maîtrise  statistique  des  procédés  et  processus. 

Pour  avoir  plus  de  détails,  il  suffit  d'acheter  le  PDF  sur  le  site  internet  ISO.org  ou  de 
suivre  un  cours  sur  le  sujet  (la  première  option  étant  plus  simple,  moins  onéreuse  et 
plus  rigoureuse).  De  toute  façon  même  si  vous  suivez  une  formation  sur  le  sujet  vous 
devrez  obligatoirement  acheter  et  lire  le  PDF.  Vous  trouverez  sur  Internet  aussi  une 
large  documentation  que  j'ai  écrite  avec  presque  toutes  les  démonstrations 
mathématiques  à  ce  sujet. 

•  ISO  9126  (niveau  Bac):  Qui  bien  qu'adressée  au  domaine  du  logiciel  peut  s'appliquer 
à  mon  avis  à  beaucoup  d'autres.  Cette  norme  précise  pour  le  produit  fini  certaines 
caractéristiques  précises  et  très  pertinentes  (mais  qui  peuvent  aussi  donc  être  utilisées 
pour  vérifier  que  la  description  du  projet  est  suffisamment  complète).  Nous  en 
donnerons  une  description  sommaire  plus  tard  dans  le  présent  document. 

•  ISO  31010  (niveau  Bac  à  Bac+7):  Je  ne  suis  pas  un  fan  de  l'ISO  31000  pour  la  gestion 
des  risques  bien  que  certains  concepts  (mais  en  très  faible  nombre)  soient  intéressants. 
Je  préfère  me  baser  sur  la  norme  ISO  31010  d'évaluation  des  risques  que  j'utilise  assez 
souvent  pour  analyser  les  erreurs  de  défaillances  potentielles  (Ishikawa,  AdP  Six 
Sigma),  la  modélisation  du  risque  (Monte-Carlo)  et  les  arbres  de  décision  (arbres  de 
Markov). 
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•  ISO  80000  (niveau  Bac  à  Bac+3):  J'essaie  d'utiliser  cette  série  de  normes  lorsque  je 
fais  de  la  mathématique  appliquée  à  la  gestion  de  projets  (donc  la  majorité  du  temps  au 
fait...)  puisqu'elle  définit  les  notations  standard  pour  les  symboles  mathématiques. 

Dans  la  gestion  de  projets,  il  est  particulièrement  important  d'utiliser  les  bonnes 
notations  dans  les  domaines  de  probabilités  et  statistiques  (norme  que  j'avais  par 
méconnaissance  dans  ma  jeunesse  pas  suivie...  mal  m'en  a  pris!)  et  dans  l'usage  des 
unités  (certaines  agences  spatiales  l'ont  appris  à  leur  dépend  aussi...). 

•  ISO  10015  (niveau  Bac):  Donne  un  guide  minimum  pour  la  formation  des  ressources 
afin  d'adapter  leurs  compétences  aux  besoins  du  projet.  Le  problème  de  cette  norme 
cependant  est  qu'elle  est  un  peu  trop  sommaire.  Il  manque  des  points  importants,  mais 
moins  cela  peut  servir  de  base  au  responsable  de  projet  qui  n'a  jamais  eu  à  gérer  la 
formation  dans  le  cadre  d'un  projet. 

•  ISO  8601  (niveau  Bac):  Donne  le  format  de  date  et  heure  international  dans  lequel  une 
date  ou  une  heure  devrait  être  écrit  sur  tout  système  ou  support.  Pas  facile  à  respecter 
tous  les  jours  d'autant  que  la  majorité  des  éditeurs  de  logiciels  et  fabricants  d'appareils 
ne  jouent  pas  le  jeu. . . 
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Cette  norme  ISO  impose  aussi  la  manière  de  compter  les  semaines  dans  une  année: 

-  la  semaine  commence  le  lundi 

-  les  jours  de  chaque  semaine  sont  numérotés  de  1  pour  le  lundi,  à  7  pour  le  dimanche 

-  la  semaine  1  est  celle  qui  contient  le  premier  jeudi  de  l'année 

La  semaine  1  est  ainsi  la  première  à  contenir  la  majorité  de  ses  jours  (au  moins  4 
jours)  dans  l'année.  Elle  contient  systématiquement  le  4  janvier.  Elle  contient 
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systématiquement  le  premier  jour  ouvré  de  l'année  en  considérant  que  le  1er  janvier, 
les  samedis  et  les  dimanches  sont  chômés.  C'est  aussi  celle  dont  le  lundi  est  le  plus 
proche  du  jour  de  l'an.  Elle  commence  au  plus  tôt  le  29  décembre  ou  au  plus  tard  le  4 
janvier. 

•  ISO  9241-11  (niveau  Bac):  Donne  les  règles  de  décision  permettant  de  déterminer  si 
un  système  est  utilisable.  C'est-à-dire  lorsqu'il  permet  à  l'utilisateur  de  réaliser  sa  tâche 
avec  efficacité,  efficience3  et  satisfaction  dans  le  contexte  d'utilisation  spécifié. 
Souvent  les  employés  dans  les  entreprises  font  l'acquisition  d'un  produit  (logiciel)  sans 
s'informer  sur  ces  points  ce  qui  est  assez  grave  pour  des  gens  censés  être  des 
professionnels  d'autant  plus  que  la  majorité  des  mes  clients  sont  des  multinationales... 

Bref  en  gros  en  2014  les  normes  relatives  à  l'analyse  statistique  peuvent  se  résumer  avec  la 
cartographie  disponible  sur  le  lien  suivant: 

https://fr.scribd.com/doc/263063855/AFNOR-Cartographie-Normes-Statistiques 

Et  pour  résumer  les  normes  ISO  à  elles  seules  avec  une  touche  d'humour  (création  personnelle 
après  une  discussion  difficile  avec  un  client): 


3  Efficacité  =  Obtenir  le  résultat,  Efficience  =  Bien  utiliser  les  ressources  pour  arriver  au  résultat 
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4.3  PMI 


■y"  (Project 


(Management 

llnstitute 


Le  Project  Management  Institute,  fondé  en  1969,  est  une  association  professionnelle  à  but 
non  lucratif  qui  propose  des  méthodes  de  Gestion  de  projet.  Son  siège  est  à  Philadelphie  en 
Pennsylvanie  (États-Unis),  elle  compte  plus  de  200'000  membres  répartis  dans  125  pays.  Elle 
publie  des  standards  relatifs  à  la  gestion  de  projets  et  est  en  charge  de  la  certification  des 
processus  de  gestion  de  projet. 

Le  PMI  est  aussi  très  connu  pour  sa  formation  et  son  ouvrage  PMBOK:  Project  Management 
Body  Of  Knowledge  (pendant  de  la  norme  ISO  10006)  qui  s'essaie  à  définir  les  compétences 
d'un  responsable  de  projets  et  les  processus  relatifs  à  une  bonne  gestion  de  projets.  C'est  un 
excellent  référentiel  pour  en  très  peu  de  temps  éviter  les  grandes  erreurs  classiques  et 
également  se  rendre  compte  qu'il  s'agit  d'un  métier  (même  si  la  majorité  des  entreprises  et  la 
personne  lambda  en  début  de  21eme  siècle  ne  l'ont  visiblement  pas  encore  compris4)! 

À  ce  titre,  le  terme  PMI  est  souvent  utilisé  pour  définir  la  méthodologie  de  gestion  de  projet 
défendue  par  le  Project  Management  Institute  dont  les  fondements  reposent  sur  9  domaines  de 
connaissance  (intégration,  contenu,  délais,  coûts,  qualité,  ressources  humaines, 
communication,  risques,  approvisionnements)  et  44  processus  y  relatifs  (le  nombre  de 
processus  évolue  en  fonction  de  la  maturité  du  modèle  et  donc  avec  les  années...). 

Selon  leur  modèle  le  projet  est  découpé  en  5  phases:  l'initialisation,  la  planification, 
l'exécution,  la  maîtrise  (ou  suivi)  et  enfin  la  clôture  (avec  le  rapport  de  revue  post¬ 
implémentation)  rassemblés  dans  un  processus  global  dont  voici  un  aperçu  (certes  ce  n'est  pas 
très  lisible  mais  vous  pourrez  l'étudier  lors  de  l'achat  du  livre): 


4  Voir  la  thèse  en  anglais  de  Paul  Giammalvo  disponible  gratuitement  au  format  électronique  sur  le  web  (PDF): 
Is  project  management  a  profession?  And  ifnot,  what  is  it? 
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ou  autrement  présenté: 


Process  group 
Knowledge  Areas 

Initiating 

Démarrage 

Planning 

Prévision 

Executing 

Réalisation 

Monitoring  &  Controlling 

Contrôler  et  Piloter 

Closing 

Clôture 

Intégration  management 

Intégration 

•  Develop  Project 
Charter 

•  Develop  Project  Management  Plan 

•  Direct  and  Manage 
Project  Execution 

•  Monitor  and  Control  Project  Work 

•  Perform  Integrate  Change  Control 

•  Close 
Project  or 
Phase 

Scope  management 

Contenu 

•  Collect  Requirements 

•  Define  Scope 

•  Create  WBS 

•  Verify  Scope 

•  Control  Scope 

Time  management 

Délai 

•  Define  Activity 

•  Sequence  Activity 

•  Estimate  Activity  Resources 

•  Estimate  Activity  Durations 

•  Develop  Schedule 

•  Control  Schedule 

Cost  management 

Coût 

•  Estimate  Cost 

•  Détermine  budget 

•  Control  Cost 

Quality  management 

Qualité 

•  Plan  Quality 

•  Perform  Quality 
Assurance 

•  Perform  Quality  Control 

Human  resource 
management 

Ressources  Humaines 

•  Develop  Human  Resource  Plan 

•  Acquire  Project  Team 

•  Develop  Project  Team 

•  Manage  Project  Team 

Communication  mngmt 

Communication 

•  Identify 
Stakeholders 

•  Plan  Communication 

•  Distribute  Information 

•  Manage  Stakeholders 
Expectations 

•  Report  Performance 

Risk  management 

Risques  &  opportunités 

•  Plan  Risk  management 

•  Identify  Risk 

•  Perform  Qualitative  Risk  Analysis 

•  Perform  Quantitative  Risk  Analysis 

•  Plan  Risk  Response 

•  Monitor  and  Control  Risks 

Procurement  management 

Approvisionement 

•  Plan  Procurements 

•  Conduct  Procurements 

•  Administer  Procurements 

•  Close 

Proc. 

Voici  les  différentes  certifications  actuelles  disponibles  au  PMI  au  jour  où  nous  écrivons  ces 
lignes: 
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PgMP  :  Program 
Management  Professional 

Connaissance  approfondie  et  minimum  4  ans 
d’expérience  (Selon  niveau  d'étude) 

CV  + 
QCM 

3  ans, 

renouvellement 
par  PDU 
(Professional 
Development 
Units) 

PMP  :  Project  Manager 
Professional 

Connaissance  approfondie  et  minimum  4  500  h 
d’expérience  (Selon  niveau  d’étude) 

Agile  Certified  Praticionner 

Connaissance  approfondie  et  minimum  3’500  h 
d’expérience  (Selon  niveau  d’étude) 

Risk  Management  Pro 

Connaissance  approfondie  et  minimum  3  000  h 
d’expérience  (Selon  niveau  d’étude) 

Scheduling  Pro 

Connaissance  approfondie  et  minimum  3’500  h 
d’expérience  (Selon  niveau  d’étude) 

CAPM  :  Certified  Associate 
Project  Manager 

Connaissance  approfondie 

QCM 

5  ans 

et  l'état  des  lieux  au  niveau  mondial: 


PMI  Fact  File 


TOTAL  MEMBERS 

533,924 

...in  208  countries 
and  territories 


Statistics  throogh  30Jun*  2018 


PMI  has  294  chartered  and 
13  potential  chapters 


More  than  6  Million  PMBOK  Guide  Editions  Now  in  Circulation! 


PUBLISHING 


CERTIFICATIONS 

|  Total  Active  Holders  of: 

CAPM  Certified  Associate  in  Project  Management 

35,849 

PMP  Project  Management  Professional 

859,893 

P  f  M  P  Portfolio  Management  Professional 

565 

P  g  M  P  Program  Management  Professional 

2,441 

PMI-RMP  PMI  Risk  Management  Professional 

4,798 

PMI -SP  PMI  Schedolmg Professional 

1,867 

P  M 1  -  P  B  A  PMi  Professional  in  Business  Analysis 

2,687 

P  M 1  -  AC  P  PMI  Agile  Certified  Practrtioner 

22,078 

EÛ 

6,025,535 

Total  copies  of 
ail  éditions*  of  the 
PMBOK *  Guide 
in  circulation 

•includes  PMI  publahed 
tranOaciom 


Formation:  ~4  jours  pour  le  PMBOK  +  ~5  jours  pour  le  PMP 
Niveau:  Bac  à  Bac+2  Bac 
Certification/Diplôme:  Oui 

Source:  www,  wikipedia.  org 
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4.4  Six  Sigma  (ISO  13053-1:2011) 

sixCT 

SIGMA 


Six  Sigma  ou  6  Sigma  (devenu  entre-temps  ISO  13053-1:201 1)  est  une  marque  déposée  de 
Motorola5  et  désignant  une  méthode  structurée  de  management  visant  à  une  amélioration  de 
la  qualité  (éliminer  les  défauts  et  la  variabilité  en  utilisant  des  outils  statistiques  avancés)  et  de 
l'efficacité  des  processus  (éliminer  le  gaspillage,  l'inutile,  automatiser  et  rationaliser  le 
répétitif,  éviter  la  redondance,  optimiser  la  production  excessive  de  bien  ou  de  documentation, 
s'interroger  sur  la  pertinence  des  tâches,  les  mouvements  ou  déplacements  inutiles,  etc.:  lean). 


8  types  «le  peit es  gaspillages 


Inventaire 


Espaces  de  travail  inadaptés 


Compétences  intellectuelles 


Surpi  o  duc  tion 


Sur- qualité  Transports  inutiles  TeinPs  dattente 


La  méthode  Six  Sigma  a  d'abord  été  appliquée  à  des  procédés  industriels  avant  d'être  élargie 
grâce  au  travail  de  chercheurs  du  MIT  (une  des  meilleures  écoles  d'ingénierie  du  monde!)  à 
tous  types  de  processus,  notamment  administratifs,  logistiques,  commerciaux  et  d'économie 
d'énergie.  Depuis  le  début  des  années  2000,  elle  connaît  un  grand  essor  en  raison  de  la 
complexité  des  organisations  et  de  l'internalisation  des  processus  qui  imposent  une  vision 
globale  des  problèmes. 

La  méthode  Six  Sigma  (ISO  13053-1:2011)  se  base  sur  une  démarche  fondée  à  la  fois  sur  la 
voix  du  client  (enquêtes,  etc.)  et  sur  des  données  mesurables  (par  indicateurs)  et  fiables  (sous 
contrôle  statistique)  le  tout  géré  comme  un  vrai  projet.  C'est  une  méthode  qui  ne  peut  être 


5  En  1981,  Bob  Gai  vin  Président  de  MOTOROLA  lance  une  démarche  de  maîtrise  de  la  dispersion  de  la 
production  afin  d'accroître  les  performances  de  l’entreprise.  En  1985,  un  ingénieur  de  MOTOROLA,  Bill  Smith, 
pose  les  bases  de  la  démarche  6  sigma  par  l'usage  des  statistiques. 
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appliquée  que  par  des  personnes  ayant  une  formation  universitaire  pointue  dans  des 
entreprises  leader  de  leur  marché  car  sa  mise  en  pratique  rigoureuse  nécessite  des 
compétences  logiques,  mathématiques  et  techniques  infiniment  plus  pointues  que  toutes  les 
autres  méthodes  citées  dans  le  présent  document. 

Le  principe  de  la  méthode  consiste  à  faire  en  sorte  que  tous  éléments  issus  du  processus 
étudié,  soient  compris  dans  un  intervalle  s'éloignant  au  maximum  de  6  Sigma  par  rapport  à  la 
moyenne  générale  des  éléments  issus  de  ce  processus.  En  réduisant  la  variabilité  des  produits 
du  processus,  on  réduit  le  risque  de  voir  le  produit  (ou  service)  rejeté  par  son  destinataire  car 
en  dehors  de  ses  attentes  ou  spécifications.  Le  principe  vise  donc  à  travailler  sur  le  processus 
afin  que  seuls  des  produits  conformes  aux  exigences  soient  livrés:  produire  juste  dès  la 
première  fois  en  éliminant  les  coûts  liés  aux  retouches,  recyclage,  mise  au  rebut  et  risque  de 
vente  d'un  produit  non  conforme. 


surproduction 
(les  5  pourquoi) 


les  7  gaspillages 


Attente 

(SMED:  Single  Minute 


îfauts  de  quali 

SPC:  Statistica 
rocess  Control 

Stc 

>cks/Flux  (Kanb; 

an) 

Remarque:  Pour  le  SMED  (Single  Minute  Exchange  of  Die)  pensez  par  exemple  au  temps  de 
changement  d'une  roue  entre  une  personne  non  entraînée  à  faire  les  bons  gestes  et  à  utiliser  les 
bons  outils  et  une  personne  qui  l'est!: 
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Temps 


30  sec 


3  min 


2  min 


4  min 


2  min 


4  min 


2  min 


30  sec 


13  min 


Idées 

d'améliorations 


Nouveau  temps 


Interne 


30  sec 


4  min 


2  min 


4  min 


30  sec 


1 1  min 


Externe 


3  min 


2  min 


2  min 


7  min 


Activités 


La  méthode  se  base  sur  5  étapes  qui  se  contractent  dans  l'acronyme  DMAAC  (ou  DMAIC  en 
anglais)  pour:  Définir,  Mesurer,  Analyser,  innover/Améliorer  (Improve  en  anglais)  et 
Contrôler. 


sigma 


et  utilise  pour  cela  de  nombreux  outils  (certains  basiques  comme  les  diagrammes  d'Ishikawa 
ou  de  Pareto  et  certains  autres  beaucoup  plus  complexes6). 

Il  existe  4  niveaux  de  reconnaissance  de  Six  Sigma  qui  suite  à  des  accords  entre  entreprises 
commencent  à  être  reconnus  au  niveau  international  depuis  2005  et  qui  sont:  le  Green  Belt 
dont  on  attend  qu'il  consacre  partiellement  son  temps  (souvent  autour  de  25%)  à  la  conduite 
de  projets  d'amélioration,  le  Black  Belt  qui  est  un  responsable  d'équipe  se  consacrant  à  plein 
temps  à  l'amélioration  et  doit  maîtriser  la  méthode  dans  son  ensemble,  le  Master  Black  Belt 
qui  est  mentor  et  formateur  de  Blacks  Belts,  garant  du  respect  de  la  démarche  et  enfin  le 
Deployment  Leader  ou  Champion,  chargé  d'élaborer  la  stratégie,  le  contenu  de  la  formation, 
les  budgets,  etc. 


6  Voir  mon  livre  sur  le  Génie  Industriel  et  les  Techniques  de  Gestion  car  le  sujet  est  trop  vaste  pour  être  abordé 
dans  la  présent  ouvrage. 


Ingénierie  de  Gestion  de  projets 


59/547 


4.4.1  Lean  Six  Sigma 

Le  lean  Six  Sigma  peut  se  résumer  grossièrement  à  une  image: 


Objectif  =  Faire  du  bon  café 


M ou  dre  I  e  café  R  em  pl  ir  de  café 


d’eau 


Ceci  n'est  pas  un  processus  "lean"  car  il  y  a  beaucoup  d'étapes  non  automatisées  et  le  goût  du 
café  dépendra  de  la  personne  qui  le  prépare  (processus  variable).  Malheureusement  je 
n'insisterai  jamais  assez:  le  lean  ne  s'applique  pas  qu'aux  ateliers  de  production/fabrication 
mais  devrait  surtout  s'appliquer  aux  départements  administratifs  où  il  y  a  selon  mon 
observation  beaucoup  trop  d'activités  faiblement  bénéficiaires  (afin  que  de  trop  nombreux 
employés  arrêtent  de  faire  des  fichiers  Excel/Word/PowePoint  à  n'en  plus  finir  et  qui  n'ont 
aucune  valeur  rajoutée  significative). 

La  solution  dans  ce  cas  serait  de  simplifier/automatiser  le  processus  afin  d'éviter  toute 
variabilité  du  processus  (quantité  de  café,  d'eau,  température  de  l'eau,  qualité  du  goût...): 


et  encore  une  fois  (!!!)  ceci  peut  très  bien  s'appliquer  aux  départements  administratifs 
(génération  manuelle  de  documents  répétitifs,  qualité  de  rédaction  des  documents,  nombre 
d'erreurs  par  documents,  niveau  de  qualité  des  documents...). 


Ingénierie  de  Gestion  de  projets 


60/547 


Vincent  ISOZ 


L'application  des  méthodes  lean  peuvent  se  résumer  aussi  très  bien  dans  les  5  points  suivants: 

•  Vos  coûts  sont  comparativement  (benchmark)  trop  élevés 

•  Vous  devez  réduire  le  temps  de  cycle  de  vos  processus 

•  Vous  voulez  optimiser  l'utilisation  de  vos  ressources 

•  Vous  pensez  que  vos  clients  ne  vont  plus  payer  vos  coûts  cachés 

•  Vous  devez  gagner  en  réactivité  et  flexibilité  (bref...  en  compétitivité) 

Formation:  -4-18  jours  selon  le  niveau  (Green  Belt,  Master  Black  Belt. . .) 

Niveau:  Bac  à  Bac+7  Bac 
Certification/Diplôme:  Oui 

Source:  www,  wikipedia.  org 


4.5  CMMi 


CMMi 


CMMi,  sigle  de  Capability  Maturity  Model  +  Intégration,  est  un  modèle  de  référence,  un 
ensemble  structuré  de  bonnes  pratiques,  destiné  à  appréhender,  évaluer  et  améliorer  les 
activités  des  entreprises  d'ingénierie. 

Le  modèle  CMMI  définit  une  échelle  de  mesure  de  la  maturité  à  5  niveaux:  Initiation  (gestion 
en  générale  chaotique),  Répétable  (processus  créés  mais  non  appliqués),  Mesures  définies 
(utilisation  et  application  des  processus),  Géré  (analyse  et  prévention  des  problèmes). 
Optimisé  (Automatisation): 


NIVEAU  Caractéristiques  Problèmes  dés  Résultat 


Chaotique 


Feed-back  dans 
le  processus 


Intuition 


Mesures 

définies 


Mesures 


Automatisation 


Anal,  et 


Gestion  en 
générale 


processus 

Processus, 

Standards 


préven.  des 
problèmes 

Utilisation  et 


application  des 


Figure  3  CMM 
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ou  une  autre  version  courante  beaucoup  utilisée  conjointement  avec  la  série  de  normes 
ISO  9000: 


Maturité 

Caractéristiques 

O-Inexistant 

•  Il  n'y  pas  de  processus 

•  Le  processus  n'est  pas  identifié  (il  n'apparaît  pas  dans  la 
cartographie) 

•  Le  processus  n'est  pas  décrit  (pas  de  fiche  processus) 

1-Inefficace 

•  Il  y  a  des  problèmes  opérationnels  majeurs 

•  Il  y  a  beaucoup  de  réclamations  clients 

•  Les  objectifs  ne  sont  pas  atteints 

•  Il  n'y  a  pas  de  boucles  d'améliorations  mises  en  oeuvre  pour  le 
processus 

•  Le  processus  n'est  pas  ou  peu  documenté 

2-Opérationnel 

•  Il  n'y  a  pas  de  problèmes  opérationnels  majeurs  ou  récurrents 

•  Le  processus  répond  majoritairement  aux  attentes  clients 

•  Certains  objectifs  sont  atteints  ou  sur  la  voie  de  l'être 

•  Des  boucles  d'amélioration  sont  initiées 

•  Le  processus  fait  l'objet  d'une  documentation  adaptée 

3-Efficace 

•  Les  processus  ont  atteint  les  objectifs  en  matière  de  qualité  et  de 
délai 

•  Il  n'y  a  plus  de  réclamation  clients  concernant  le  processus 

•  Les  boucles  d'amélioration  du  processus  sont  opérationnelles 

4-Effîcient 

•  Le  processus  atteint  tous  ces  objectifs,  y  compris  ceux  en  matière 
de  coût  ou  de  rentabilité 

•  Toutes  les  étapes  du  processus  sont  mesurées  ou  pour  le  moins 
estimées  quantitativement 

•  La  majorité  des  clients  expriment  leur  satisfaction 

•  Les  boucles  d'amélioration  ont  prouvé  leur  efficacité 

5-Excellent 

•  Les  clients  ne  sont  pas  seulement  satisfaits  mais  parfois  même 
surpris  (le  processus  va  au-delà  de  leurs  attentes) 

•  L'entreprise  est  reconnue  comme  "best  in  class"  (la  référence) 
pour  ce  processus  dans  des  opérations  de  benchmarking  (études 
comparatives) 

•  Le  processus  est  sous  contrôle  statistique  (cartes  de  contrôle) 

•  Les  salariés  qui  mettent  en  oeuvre  le  processus  sont  satisfaits  de 
leurs  conditions  de  travail 

Évidemment  les  entreprises  au  niveau  1  et  2  ne  réalisent  très  souvent  pas  l'importance  et  le 
pouvoir  que  leur  donne  une  structure  de  gestion  de  projets  professionnelle.  Elles  consacrent 
peu  de  temps  aux  étapes  préliminaires  et  perdent  beaucoup  d'énergie  dans  les  étapes  suivantes 
de  développement.  Leur  taux  de  réussite  de  projets  n'est  pas  sous  contrôle  statistique.  Pour  les 
autres  niveaux,  il  est  assez  facile  de  deviner  de  quoi  il  en  retourne. 

Ce  modèle  a  été  réalisé  par  un  ingénieur  du  département  de  la  défense  américain  afin  d'être  en 
mesure  de  donner  des  informations  concrètes  aux  problèmes  de  la  qualit  suite  à  des  pannes 
logiciels. 
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Formation:  ~3  à  5  jours 
Niveau:  Bac  à  Bac+3  Bac 
Certification/Diplôme:  Oui 

Source:  www,  wikÿjedia,  org 

4.6  AFITEP 


•ARTEP 


L'AFITEP  est  l’Association  Francophone  de  Management  de  Projet  dont  des  ingénieurs  et 
chercheurs  très  réputés  dans  le  monde  francophone  sont  membres  et  qui  délivre  des 
certifications  aux  personnes  physiques. 

L’association  délivre  une  Certification  en  Gestion  de  Projet  (CGP)  ainsi  qu’une  Certification 
en  Direction  de  Projet  (CDP)  délivrée  aux  directeurs  et  responsables  de  projets  et  reconnue 
par  l’International  Project  Management  Association  (IPMA). 

Niveau:  Bac  à  Bac+2 

Source:  www,  wikipedia.  ors 

4.7  IPMA 


International 

Project 

Management 

Association 


L’International  Project  Management  Association  (IPMA),  créée  en  1965  par  l'Allemagne  - 
France-Grande  Bretagne  (avec  siège  en  Suisse. . .),  a  pour  principale  tâche  de  proposer  une 
solution  répondant  aux  besoins  de  compétences  en  management  de  projet.  Avec  son  système 
de  certification  à  quatre  niveaux,  l’IPMA  permet  de  déterminer  quand  un  spécialiste  ou  un 
cadre  est  qualifié  pour  diriger  un  projet.  Le  système  de  certification  de  D-A  dans  l’ordre  de 
difficulté  s'appuie  sur  la  définition  exhaustive  de  la  compétence  en  management  de  projet. 

-  IPMA  Niveau  A:  Désigne  une  personne  qui  est  capable  de  diriger  des  portefeuilles  ou 
des  programmes  importants  au  moyen  des  ressources,  méthodes  et  instruments 
correspondants.  C'est  bien  cela,  l'objet  de  la  certification  Level  A,  et  non  pas  le 
management  de  projets  individuels.  Cette  responsabilité  exige  une  forte  dose  de 
connaissances  et  d'expérience  (34  personnes  certifiées  au  total  Suisse  en  2009  depuis 
l'implémentation  de  l'IPMA  ;  278  dans  le  monde). 

IPMA  Niveau  B:  Désigne  une  personne  capable  de  gérer  un  projet  complexe.  Celui-ci 
inclut  normalement  des  sous-projets,  c'est-à-dire  que  le  manager  de  projet  gère  le  projet 
avec  l'aide  de  managers  de  sous-projets  et  se  consacre  moins  à  la  conduite  du  groupe  de 
projet  (706  personnes  certifiées  au  total  Suisse  en  2009  depuis  l'implémentation  de 
l'IPMA  ;  6'154  dans  le  monde). 
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IPMA  Niveau  C:  Désigne  une  personne  qui  est  en  mesure  de  gérer  un  projet  d'une 
complexité  limitée.  Cela  signifie  que  le  candidat  dispose  du  savoir  et  de  l'expérience  du 
management  de  projet  nécessaires  pour  conduire  efficacement  un  projet  (855  personnes 
certifiées  au  total  Suisse  en  2009  depuis  l'implémentation  de  l'IPMA  ;  27'861  dans  le 
monde). 

-  IPMA  Niveau  D:  Désigne  une  personne  qui  est  capable  de  mettre  en  pratique  ses 

connaissances  en  management  de  projet  dans  le  cadre  de  sa  participation  à  un  projet,  en 
sachant  que  des  connaissances  spécifiques  complètes  et  fondamentales  sont  nécessaires 
dans  le  management  de  projet  (2147  personnes  certifiées  au  total  Suisse  en  2009  depuis 
l'implémentation  de  l'IPMA  ;  1 1 1  '283  dans  le  monde). 

L'ICB  (IPMA  Compétence  Baseline)  référentiel  international  qui  définit  les  connaissances  et 
l’expérience  attendues  des  chefs  de  projet  (conformité  ISO  9001:2000  et  ISO/IEC  Standard 
17024:2003): 


Avec  au  niveau  des  certifications  au  jour  où  nous  écrivons  ces  lignes: 
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A 

Directeur  de  projet 
Project  Director 

Connaissance 
et  expérience 

CV 

+  Auto  évaluation 
+  Liste  de  projets 
+  références 

Rapport 

5  ans 

B 

Chef  de  projet 

Senior  Project 

Manager 

5  ans 

C 

Responsable  de  projet 
Project  Manager 

Examen  écrit 
+  Rapport 

5  ans 

D 

Assistant  de  projet 
Project  Management 
associate 

Connaissance 

CV 

+  Auto  évaluation 

Examen  écrit 

5  ans, 
option  10 
ans 

Formation:  -15-20  au  total  pour  les  quatre  niveaux 
Niveau:  Bac  à  Bac+2  Bac 
Certification/Diplôme:  Oui 

Source:  www.vzpm.ch 

4.8  ITIL 

ITIL* 

nrttwto  Managing  IT  service! 

ITIL  (Information  Technology  Infrastructure  Library)  est  un  ensemble  d'ouvrages  recensant 
les  bonnes  pratiques  pour  la  gestion  des  services  informatiques,  édictées  par  l'Office  public 
britannique  du  Commerce  (OGC). 

L'adoption  des  bonnes  pratiques  de  l'ITIL  par  une  entreprise  permet  d'assurer  à  ses  clients 
(internes  comme  externes)  un  service  répondant  à  des  normes  de  qualité  préétablies  au  niveau 
international.  ITIL  est  à  la  base  de  la  norme  BS  15000  (première  norme  de  Gestion  de  Services 
Informatiques  formelle  et  internationale)  un  label  de  qualité  proche  des  normes  de  l'ISO  par 
exemple  (ISO/IEC  20000). 

ITIL  permet,  grâce  à  une  approche  par  processus  clairement  définie  et  contrôlée,  d'améliorer 
la  qualité  des  SI  et  du  support  aux  utilisateurs  en  créant  notamment  la  fonction  de  Centre  de 
services  qui  centralise  et  administre  l'ensemble  de  la  gestion  des  systèmes  d'informations. 
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Exigences 

business 

Étapes  du 
cycle  de  vie 
des  service 
de  ITIL®  2011 


Processus 

informatiques 


Processus  business  /  résultats  business 


Stratégie 
des  services 


Fonctions 
informatiques 
et  engagement 
dans  le  cycle  de 
vie  des  services 


Sources  de 
connaissance  I 
leçons  apprises 

Engagement 
du  fournisseur 
de  services 


Gestion  de 
la  stratégie 

Gestion  du 
portefeuille 
de  services 
Gestion  financière 
des  services 
informatiques 
Gestion  de 
la  demande 
Gestion  des 
relations  business 


Conception 
des  services 


Transition 
des  services 


Exploitation 
des  services 


Amélioration 
continue  des 
services 


Coordination  de 
la  conception 
Gestion  des 
niveaux  de  service 
Gestion  du  catalogue 
de  services 
Gestion  de  la 
disponibilité 
Gestion  de 
la  capacité 
Gestion  de  la 
continuité  de  services 
Gestion  de  ta  sécurité 
de  l'information. 
Gestion  des 
fournisseurs 


Planification  et 
support  à  la  transition 
Gestion  des 
changements 
Gestion  des  actifs 
de  service  et  des 
configurations 
Gestion  des 
déploiements  et  des 
mises  en  production 
Validation  et  tests 
de  service 
Évaluation  des 
changements 
Gestion  des 
connaissances 


Gestion  des 
événements 

Gestion  des  incidents 
Exécution 
des  requêtes 
Gestion  des 
problèmes 
Gestion  des  accès 


Le  processus 
d'amélioration 
en  sept  étapes 


Gestion  technique  et  gestion  des  applications 


Centre  de  services 


Gestion  des  opérations  informatiques 


Gestion  des  connaissances  de  service,  portefeuille  et  catalogue  de  services,  accords  / 
plans  de  services,  processus  et  procédures,  gabarits,  tests,  évaluation,  résultats,  etc. 
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Les  bénéfices  pour  l'entreprise  sont  une  meilleure  traçabilité  de  l'ensemble  des  actions  du 
département  informatique.  Ce  suivi  amélioré  permet  d’optimiser  en  permanence  les  processus 
des  services  pour  atteindre  un  niveau  de  qualité  maximum  de  satisfaction  des  clients. 

Pour  les  individus,  il  existe  3  niveaux  de  certifications  pour  ITIL  à  ce  jour: 

-  Foundation  Certificate:  Certification  de  premier  niveau  accordée  après  un  test  sous 
forme  de  questions  à  choix  multiples,  qui  suit  normalement  un  cours  de  2  à  3  jours  chez 
un  formateur  accrédité.  Ce  certificat  valide  une  connaissance  générique  des 
fondamentaux  d'ITIL. 


-  Practitioners  Certificates:  Certifications  accordées  pour  une  discipline  spécifique  après 
un  cours  de  2  à  3  jours  chez  un  formateur  accrédité  et  un  test  sous  forme  de  questions  à 
choix  multiples  fondé  sur  un  cas  concret.  Le  Foundation  Certificate  est  un  prérequis. 

-  Managers  Certificate:  Certification  accordée  après  deux  tests  de  3  heures  qui  suivent 
une  formation  de  10  jours  par  un  formateur  accrédité.  Le  Foundation  Certificate  est  un 
prérequis. 

Formation:  ~2  jours 
Niveau:  Bac  à  Bac+1  Bac 
Certification/Diplôme:  Oui 

Source:  www  wikipedia.  ors 


Ingénierie  de  Gestion  de  projets 


66/547 


Vincent  ISOZ 


4.9  COBIT 


GOVERNANCE,  CONTROL  and 
ASSURANCE  for  INFORMATION 
and  RELATËD  TECHNOLOGY 


COBIT  (Control  Objectives  for  Information  and  Related  Technology)  définit  les  meilleures 
pratiques  de  gouvernance  pour  les  responsables  informatiques. 

Ce  standard  propose  une  démarche  pour  gérer  les  services  informatiques  comme  une 
ressource  qui  permet  d'apporter  de  la  valeur  et  de  mettre  en  œuvre  une  stratégie  de  gestion  des 
risques  efficace. 

COBIT  propose  un  ensemble  complet  de  processus,  d'objectifs  de  contrôle,  de  métriques  et 
d'indicateurs  pour  un  large  éventail  de  processus  informatiques  en  intégrant  d'autres 
référentiels,  normes  ou  ressources,  comme  entre  autres  :  la  Val  IT  et  le  IT  Risk  de  l'ISACA,  le 
référentiel  ITIL  et  les  normes  connexes  de  l'ISO,  TOGAF,  PMBOK,  Prince2,  COSO,  PCI 
DSS,  la  loi  Sarbanes-Oxley  Act  et  Bâle  III.  C'est  cette  synérgie  qui  fait  que  selon  moi  COBIT 
devrait  être  LE  référentiel  dans  le  domaine  de  ITT. 

Formation  AMDEC:  ~5  jours 
Niveau:  Bac  à  Bac+5  Bac 
Certification/Diplôme:  Oui 

4.10  AMDEC 

AMDEC  est  la  traduction  de  l'anglais  FMECA  (Failure  Modes,  Effects  and  Criticality 
Analysis,  littéralement  "Analyse  des  Modes  de  Défaillance  et  de  leur  Criticité").  La  version 
non  mathématique  est  nommée  AMDE  est  donc  simplement  la  traduction  de  FMEA.  Il  s'agit 
d'une  prolongation  de  l'analyse  fonctionnelle.  C'est  encore  une  fois  l'armée  américaine  qui  est 
à  l'initiative  du  développement  de  l'AMDEC.  La  référence  militaire  MIL-P-1629  date  de 
novembre  1949. 

L'AMDE  est  essentiellement  une  démarche  inductive,  aussi  exhaustive  que  possible,  qui 
consiste  à  identifier  au  niveau  d'un  système  ou  d'un  de  ses  sous-ensembles,  les  modes 
potentiels  de  défaillance  de  ses  éléments,  leurs  causes  et  leurs  effets.  De  telles  analyses 
peuvent  être  adaptées  à  toute  interrogation  dans  tout  domaine  et  peuvent  servir  de  base,  entre 
autres,  aux  analyses  fiabilité,  maintenabilité,  disponibilité,  qualité  et  testabilité.  Evidemment 
de  nombreuses  personnes  (souvent  des  soft  skill)  considèrent  que  c'est  inutile  car  de  toute 
façon  on  ne  peut  pas  lister  toutes  les  défaillances  potentielles.  Donc  l'AMDE  ou  l'AMDEC  ne 
doit  être  vu  comme  un  outil  et  certains  mauvais  esprits  parleront  même  d'utopie  ou 
d'idéologie... 
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L'AMDE  privilégie  trois  types  d'actions  principales  qui  sont  (et  que  l'on  retrouve  aussi  dans  le 

PMI/PMBOK  V4): 

1.  La  maintenance  préventive  qui  est  axée  sur  la  correction  des  défauts  des 
applications,  en  vue  de  minimiser  le  risque  d'une  répétition  des  problèmes.  Les 
interventions  de  maintenance  préventive  comprennent  la  restructuration  des  codes 
sources,  la  réorganisation  des  bases  de  données  et  la  réécriture  des  programmes. 

2.  La  maintenance  corrective  qui  consiste  à  réparer  les  défauts  qui  empêchent  une 
application  ou  une  machine  de  fonctionner  correctement.  Elle  consiste  donc  à  régler 
des  problèmes  opérationnels  ou  à  corriger  des  anomalies  qui  entravent  l'exécution  d'un 
processus.  La  maintenance  corrective  exige  un  soutien  7  jours/24  heures,  afin  de 
maintenir  les  applications  à  leur  efficacité  maximale. 

3.  La  maintenance  adaptative  a  pour  but  d'améliorer  constamment  les  applications 
selon  l'évolution  des  besoins  de  l'entreprise.  Les  améliorations  peuvent  prendre 
diverses  formes:  les  mises  à  niveau  logicielles,  les  modifications  exigées  par  la 
réglementation,  l'intégration  de  systèmes,  etc.  La  maintenance  adaptative  s'assure  que 
les  applications  progressent  au  rythme  des  changements  constants  qui  surviennent,  que 
ceux-ci  soient  d'origine  commerciale,  technologique  ou  réglementaire. 

Le  but  est  de  hiérarchiser  les  actions  d'amélioration  à  conduire  sur  un  processus,  un  produit, 

un  système  en  travaillant  par  ordre  de  criticité  décroissant. 

Formation  AMDE:  ~2  jours 

Formation  AMDEC:  ~5  jours 

Niveau:  Bac  à  Bac+7 

Source:  www  wikipedia.  ors 

4.11  PRINCE2 

PRINCE2 

project  management 


PRINCE2  (PRojects  IN  Controlled  Environments)  est  une  méthode  de  gestion  et  de 
certification  de  projet  structurée  qui  se  focalise  sur  trois  points:  l'organisation,  la  gestion  et  le 
contrôle  du  projet.  PRINCE  est  divisé  en  huit  processus  définis  par  des  clés  d'entrée  et  de 
sortie,  des  objectifs  à  atteindre  et  des  activités  à  réaliser  regroupées  en  4  phases  (au  lieu  de  5 
pour  le  PMI  et  Six  Sigma):  Démarrage,  Initialisation,  Exécution,  Clôture. 

Il  existe  deux  types  de  certification  PRINCE2,  reconnues  dans  le  monde  entier: 

PRINCE2  Fundamentals:  Cet  examen  vérifie  qu'un  collaborateur  dispose  des 
connaissances  nécessaires  pour  participer  à  un  projet  géré  selon  la  méthode 
PRINCE2™.  La  réussite  de  cet  examen  et  ainsi  l'obtention  du  certificat  passe  par  la 
maîtrise  des  principes  et  de  la  terminologie  de  la  méthode. 

-  PRINCE2  Praticien:  Cet  examen  est  la  garantie  d'une  maîtrise  parfaite  de  la  méthode 
pour  gérer  un  projet  et  être  capable  d'appliquer  et  d'adapter  les  principes  de  la  méthode 
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PRINCE2™  pour  anticiper  les  attentes  et  éviter  ou  prévoir  les  problèmes  d'un  projet 
donné. 

La  méthode  PRINCE  est  divisée  en  8  processus.  Chaque  processus  est  désigné  par  une 
abréviation:  Elaborer  un  projet  (EP),  Initialiser  un  projet  (IP),  Diriger  un  projet  (DP), 
Contrôler  une  séquence  (CS),  Gérer  la  livraison  de  produits  (LP),  Gérer  les  limites  de 
séquences  (LS),  Clore  un  projet  (CP),  Planifier  (PL). 

Les  huit  processus  sont  regroupés  de  la  manière  suivante: 


Note  1:  à  la  fin  de  la  séquence  d'initialisation,  le  processus  Initialiser  le  Projet  est  utilisé  pour  demander  au  Comité  de 
Pilotage  de  Projet  d'approuver  l'initialisation  du  projet  (en  soumettant  la  Documentation  d'initialisation  de  Projet)  et 
en  même  temps,  le  processus  Gérer  une  Limite  de  Séquence  est  utilisé  pour  demander  au  Comité  de  Pilotage  de  Projet 
d'approuver  le  Plan  de  Séquence  de  la  seconde  séquence  management. 

Note  2:  les  activités  de  clôture  sont  planifiées  et  approuvées  lors  de  l'approbation  de  la  séquence  finale.  Ainsi,  le  processus 
Clore  le  Projet  se  passe  durant  la  dernière  séquence. 

Figure  4  Modèle  PRINCE2 


Avec  au  niveau  des  certifications  au  jour  où  nous  écrivons  ces  lignes: 
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Practitioner 

Connaissance  approfondie 

QCM 

3  ans  à  5  ans, 
renouvellement  par  examen 

Foundation 

Connaissance 

QCM 

Vie 

Formation:  ~5  jours 
Niveau:  Bac 

Certification/Diplôme:  Oui 

4.12  BPF 


Les  Bonnes  Pratiques  de  Fabrication  (BPF),  en  anglais  Good  Manufacturing  Practices  - 
GMP,  est  une  notion  d'assurance  de  la  qualité  qui  fait  partie  intégrante  de  la  gestion  de  projets 
d'entreprises  industrielles  mais  qui  peut  très  bien  s'appliquer  au  administration  sous  la 
dénomination  de  Bonnes  Pratiques  de  Travail. 

La  production  d'un  bien  de  consommation  (alimentaire,  logiciel  ou  véhicule)  doit  souvent  être 
conforme  à  des  spécifications  définies  dans  l'autorisation  de  mise  sur  le  marché  et  ne  devant 
pas  exposer  le  consommateur  à  un  risque  remettant  en  cause  la  sécurité,  la  qualité  ou  à 
l'efficacité  du  produit. 

Dans  cet  esprit,  les  BPF  s'attachent  à  limiter  5  catégories  principales  de  risques: 

1.  Les  risques  de  contamination  croisée  des  produits  (par  un  autre  produit,  ou  un 
contaminant  interne  et  externe)  dans  le  cas  alimentaire  ou  médical. 

2.  Les  risques  de  confusion  notamment  au  niveau  des  étiquetages  et  de  l'identification 
des  composants  ainsi  que  de  leur  documentation. 

3.  La  propreté  (hygiène)  de  l'environnement  de  production  et  de  fabrication  qui  doit 
permettre  d'éviter  que  des  corpos  étrangers  s'immiscent  dans  le  produit. 

4.  Le  non  respect  des  normes,  étalons  et  standards  à  travers  une  organisation  rigoureuse 
de  l'entreprise. 

5.  S'assurer  que  les  intervenants  sur  le  produit  et  les  responsables  aient  les  compétences 
nécessaires  pour  éviter  au  maximum  les  risques. 
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Les  10  grandes  lignes  de  la  BPF  sont  (nous  retrouvons  au  fait  ces  10  points  dans  d'autres 
domaines  de  la  gestion  de  projets  et  pas  que  la  fabrication!): 

* 

1.  ECRIRE  les  modes  opératoires  et  les  instructions  afin  de  fournir  une  "feuille  de 
route"  nécessaire  à  la  conformité  aux  BPF  et  à  une  production  de  qualité  régulière. 

2.  SUIVRE  scrupuleusement  procédures  et  instructions  pour  prévenir  toute 
contamination,  inversion  ou  erreur. 

3.  RENSEIGNER  rapidement  et  précisément  le  travail  en  cours  dans  un  but  de 
conformité  aux  procédures  et  de  traçabilité. 

4.  PROUVER  que  nos  systèmes  font  ce  pour  quoi  ils  sont  conçus  en  effectuant  des 
démarches  formelles  de  validation. 

/ 

5.  INTEGRER  la  productivité,  la  qualité  du  produit  et  la  sécurité  du  personnel  dans  la 
conception  des  bâtiments  et  des  équipements. 

6.  EFFECTUER  LA  MAINTENANCE  des  bâtiments  et  équipements  de  manière 
régulière  et  efficace. 

7.  DÉVELOPPER  ET  DÉMONTRER  clairement  les  compétences  au  poste  de  travail. 

8.  PROTÉGER  les  produits  contre  toute  contamination  en  adoptant  des  habitudes 
régulières  et  systématiques  de  propreté  et  d'hygiène. 

9.  CONSTRUIRE  LA  QUALITÉ  dans  les  produits  par  un  contrôle  des  matières 
premières  et  des  processus  tels  que  la  fabrication,  l'emballage,  l'étiquetage. . . 

10.  PLANIFIER  et  EFFECTUER  régulièrement  des  audits  afin  d'assurer  conformité  au 
BPF  et  efficacité  du  système  qualité 

Ces  principes  sont  souvent  résumés  autour  des  "5M": 

-  Matériel  (identifié,  entretenu,  nettoyé,  qualifié...) 

-  Méthodes  (disponibles,  détaillées,  précises,  vérifiées,  validées,  auditées...) 

-  Main-d'œuvre  (formée  et  habilitée  au  poste  de  travail) 

-  Matières  (identifiées,  contrôlées...) 

-  Milieu  (infrastructures  de  production  qualifiées  ...) 

qui  sont  souvent  identifiées  et  associées  aux  diagrammes  d'Ishikawa  (que  nous  verrons  plus 
tard)  et  à  la  méthode  AMDEC. 

Niveau:  Bac  à  Bac+1 
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4.13  5S 


La  méthode  des  5S,  qui  tire  son  origine  de  la  première  lettre  de  chacune  des  cinq  opérations, 
est  une  technique  de  management  japonaise.  Elle  est  tirée  du  Système  de  Production  Toyota 
(TPS)  et  repose  sur  cinq  principes  simples: 

Seiri  (SS,  Débarras),  Seiton  (S'il  Rangement),  Seiso  (/il Ht,  Nettoyage),  Seiketsu  (/H/fü, 
Ordre),  Shitsuke  (ü,  Rigueur) 

Elle  doit  être  organisée  sur  la  base  d'objectifs  de  rangement  et  de  gains  de  temps  afin  de 
faciliter  le  transfert  de  connaissances  et  l'automatisation  facilitée  des  habitudes. 

Formation:  ~2  jours 
Niveau:  Bac  à  Bac+1 

Source:  www,  wikipedia.  org 

4.14  SWOT 


J.trengths 

VVeaknesses 

Upportunities 


L'analyse  SWOT  (de  l'anglais  Strengths  (forces),  Weaknesses  (faiblesses),  Opportunities 
(opportunités),  Threats  (menaces),  est  un  outil  de  stratégie  d'entreprise  permettant  de 
déterminer  les  options  stratégiques  envisageables  au  niveau  d'un  domaine  d'activité  précis. 


Positif 

{pour  atteindre  l'objectif) 
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Niveau:  Bac 


Source:  www,  wikipediçç  org 

4.15  IFCAM 

->  urcnm 

Institut  suisse  pour  la  formation  des  chefs  d'entreprise 

L'Institut  suisse  pour  la  formation  des  chefs  d'entreprise  existe  depuis  1966.  C'est  son 
ancienneté  et  sa  localisation  dans  les  trois  régions  principales  de  la  Suisse  (suisse-romande, 
suisse-allemande  et  suisse-italienne)  qui  fait  sa  réputation  au  niveau  national.  Outre  le  fait  que 
cet  institut  propose  les  certifications  IPMA  et  PMP  son  importance  réside  dans  le  fait  qu'il 
propose  un  diplôme  fédéral  d'économiste  d'entreprise  en  formation  continue. 

Niveau:  Bac  à  Bac+3 


4.16  SPICE 


■  ji  ^ 

SPlCC 

Le  standard  ISO/IEC  15504  initialement  connu  sous  le  nom  de  SPICE  (Software  Process 
Improvement  and  Capability  dEtermination)  permet  l'évaluation  des  processus  de 
développement  informatique  et  est  aujourd'hui  utilisé  dans  de  nouveaux  secteurs  (dont  la 
gestion  des  services  informatiques  avec  TIPA).  Il  s'agit  grossièrement  d'un  mélange  d'ITIL  et 
CMMi. 

4.17  Hermes 

normes 

HERMES  est  une  méthode  ouverte  officielle  de  la  Confédération  Suisse  pour  la  conduite  et  le 
déroulement  uniforme  et  structuré  de  projets  dans  le  domaine  des  technologies  de 
l'information  et  de  la  communication  (TIC).  La  méthode  est  obligatoire  au  sein  de  la 
Confédération  et  doit  être  utilisée  dans  tous  les  projets  TIC.  HERMES.  Elle  est  également 
utilisée  dans  d'autres  administrations  publiques,  des  hautes  écoles  et  des  entreprises. 

Pour  structurer  le  déroulement  d'un  projet,  HERMES  divise  l'ensemble  de  la  démarche  en  six 
phases:  Initialisation,  Analyse  préliminaire,  Conception,  Réalisation,  Introduction, 
Finalisation.  Contrairement  à  des  méthodes  orientées  processus  et  pôles  de  compétence 
(comme  PMI/IPMA),  HERMES  est  plus  orienté  phasing  de  projets. 
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RESULTAT 


Proposition  de  projet 
Rapport  Evaluation 
Rapport  Analyse  préliminaire 


Manuel  d'exploitation 
Design  du  système 


DEMARCHE 


Activité  1 

Etape  de  travail  1 
Etape  de  travail  2 
Activité  2 
Etape  de  travail  4 
Etape  de  travail  5 
Etape  de  travail  6 
Activité  3 


ROLE 


Chef  de  projet 
Donneur  d'ordre 
Architecte  de  solution 
Représentant  des 
utilisateurs 
Responsable  de  la 
qualité 

Responsable  des 
risques 


Remarque:  Cette  méthodologie  de  gestions  de  projets  n'a  pas  empêchée  la  confédération 
d'avoir  certains  projets  informatiques  aberrants  et  certains  dont  les  coûts  ont  largement 
dépassé  le  budget  initial  (cf.  projet  du  Système  de  Conduite  et  d'information  des  Forces 
Terrestres). 

Il  existe  deux  certifications  reconnues  au  niveau  fédéral  au  jour  où  nous  écrivons  ces  lignes: 

HERMES  Swiss  Project  Team  Professional  HSPTP:  Assure  les  compétences  pour 
participer  en  tant  que  collaborateur  de  projet  à  un  projet  conduit  selon  la  méthode. 

HERMES  Swiss  Project  Manager  HSPM:  Assure  la  capacité  d'appliquer  avec  succès  et 
méthodiquement  les  connaissances  et  l'expérience  de  projet  en  situation. 


HSPM  (HERMES  Swiss 
Project  Manager) 

Connaissance  approfondie 

QCM 

4  ans 

FHSPTP  (HERMES  Swiss 
Project  Team  Professional) 

Connaissance 

Oral  et  écrit 

4  ans 

Formation:  ~2  à  6  jours  selon  le  niveau  souhaité 
Niveau:  Bac  à  Bac+1 

(signalons  que  tous  PDFs  sont  gratuits  sur  le  site  internet  de  la  confédération!). 
Source:  vi’vvvv.  hermes.  adinin.ch 
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4.18  Agile 

Concrètement,  la  méthode  Agile  signifie  que  nous  ne  formalisons  pas  de  cahier  des  charges, 
qui  est  par  nature  rigide  et  pas  adapté  aux  petits  projets  compris  entre  un  coût  nul  et  environ 
l'OOO'OOO.-. 

Effectivement,  traditionnellement,  beaucoup  de  clients  s'attendent  à  ce  que  leur  prestataire 
travaille  au  forfait.  Ainsi,  le  client  a  l'illusion  de  ne  prendre  aucun  risque  en  termes  de  budget 
et  de  délai,  en  supposant  que  son  prestataire  sera  capable  de  tenir  ses  engagements. 

Dans  la  pratique,  le  client  et  le  prestataire  s'accordent  sur  les  contours  exacts  de  leur  relation 
commerciale  par  le  biais  un  contrat.  Ce  contrat  va  définir  un  cadre  strict  en  termes  de  coûts, 
de  délais  et  surtout  de  périmètre  fonctionnel  du  produit  à  développer. 

Ce  périmètre  strict  et  rigide  va  être  consigné  dans  un  interminable  cahier  des  charges.  Celui-ci 
va  être  interprété  par  le  prestataire  qui  va  soumettre  son  offre  commerciale.  Enfin,  le  client  et 
le  prestataire  s'engagent  dans  la  réalisation  du  produit...  et  c'est  souvent  le  début  des 
problèmes! 

Qu'est-ce  qu'il  se  passe  dans  l'énorme  majorité  des  cas?  Le  prestataire  perçoit  son  acompte, 
s'isole,  travaille  dans  son  coin  et  tête  baissée  pendant  plusieurs  mois  tout  en  posant  une  ou 
deux  questions  à  son  client,  de  temps  à  autre... 

En  toute  bonne  foi,  et  convaincu  d'avoir  accompli  un  excellent  travail,  le  prestataire  revient 
vers  son  client  après  des  mois  de  travail  avec  une  version  aboutie  de  son  point  de  vue  à  lui, 
d'informaticien... 

Le  client  s'empresse  de  découvrir  le  produit  mais  il  très  vite  déçu...  De  son  point  de  vue  à  lui, 
d'utilisateur,  il  manque  des  fonctionnalités  pourtant  triviales  et  essentielles  à  son  travail, 
l'ergonomie  n'est  pas  bonne,  le  produit  ne  tient  pas  compte  de  certains  processus  d'entreprise 
déjà  bien  établis,  etc. 

Déception  et  surprise  aussi  chez  le  prestataire,  qui  argumente  que  telle  fonctionnalité 
manquante  n'est  pas  explicitement  mentionnée  dans  le  cahier  des  charges  et  qu'il  suffit  de 
cliquer  ici  et  passer  par  là  dans  l'interface  pour  aboutir  au  même  résultat. 

Le  client,  en  toute  bonne  foi,  insiste  que  telle  ou  telle  fonctionnalité  est  sous-entendue  dans  tel 
paragraphe  car  sans  cela,  telle  autre  chose  aurait  peu  ou  pas  d'utilité.  Pour  le  client  qui,  c'est 
une  question  de  bon  sens...  et  il  ne  comprend  pas  que  le  prestataire  n'y  ait  pas  pensé  par  lui- 
même!  Au  passage,  le  client  remarque  qu'il  faudrait  encore  ajouter  cette  petite  fonction,  mais 
qu'il  s'agit  certainement  d'un  tout  petit  changement  et  vu  le  montant  du  forfait,  le  prestataire 
peut  bien  inclure  gracieusement  cette  petite  demande  supplémentaire.... 

S'ensuivent  de  pénibles  échangent  entre  deux  parties,  chacune  se  sentant  frustrée  et  lésée... 

Le  client  a  beaucoup  attendu,  il  a  même  certainement  été  plus  patient  que  prévu  en  supportant 
des  dépassements  de  délais  car  le  prestataire  avait  sous-estimé  la  masse  totale  de  travail  ou 
peut-être  l'avait-il  fait  volontairement  pour  décrocher  le  mandat?  De  plus,  le  montant  global 
de  la  facture  est  conséquent  et  d'autant  plus  que  le  produit  livré  (et  prétendu  conforme  au 
cahier  des  charges,  du  point  de  vue  du  prestataire)  ne  correspond  pas  aux  attentes  du  client, 
qui  est  sensé  travailler  avec  ce  produit  au  quotidien,  et  ce  depuis  un  moment  déjà... 
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Le  prestataire,  de  bonne  foi  également,  a  le  sentiment  que  son  client  cherche  des  excuses  pour 
ne  pas  payer  le  solde  de  la  facture.  Pourtant,  de  son  point  de  vue,  tout  est  fonctionnel  et 
conforme  au  cahier  des  charges  qui  stipule  tout,  noir  sur  blanc.  Le  prestataire  a  déjà  le 
sentiment  d'avoir  été  perdant  en  ayant  largement  dépassé  le  temps  qu'il  avait  estimé  sur  ce 
projet.  De  plus,  il  a  consentit  à  quelques  sacrifices  et  cadeaux  mais  a  la  nette  impression  que 
son  travail  n'est  pas  valorisé...  En  conséquence,  sa  motivation  baisse  et  la  qualité  du  produit 
en  ressent  lourdement. 

Bref,  tout  le  monde  est  perdant  ! 

Les  problèmes  du  cahier  des  charges  c'est  que  contrairement  au  monde  du  bâtiment  ou  à 
d'autres  domaines  ou  la  rigidité  pourrait  être  une  qualité,  ce  n'est  pas  le  cas  des  produits  de  la 
majorité  des  développements  informatiques,  qu'il  s'agit  d'un  logiciel  ou  d'une  application  web 
à  développer  sur  mesure,  qui  sont  de  petites  applicatons  pour  lesquelles  il  n'y  pas  de  vies  en 
jeu,  ni  de  normes  industrielles,  ni  de  très  grosses  quantités  d'argent. 

Dans  la  pratique,  le  cahier  des  charges  pose  plusieurs  problèmes  relativement  à  ce  genre  de 
petits  projets  informatiques  ou  de  projets  informatiques  à  faible  criticité: 

1 .  il  ne  peut  prévoir  tous  vos  besoins  et  nouvelles  idées  que  vous  découvrirez  au  fur 
et  à  mesure  en  avançant  dans  votre  projet 

2.  il  est  souvent  sujet  à  maladresses  de  rédaction,  zones  floues  et  forcément 
interprétations  de  lecture...  et  donc  à  des  conflits  potentiels 

3.  il  enlève  toute  flexibilité  au  projet  et  vous  limite  quant  aux  changements  utiles  et 
bienvenus 

4.  il  est  pénible  et  long  (et  donc  coûteux)  à  préparer...  temps  et  argent  que  l'on  fait 
mieux  à  investir  dans  l'analyse  et  la  réflexion  préalable,  étude  de  l'ergonomie  et  la 
qualité  du  produit 

5.  pour  toutes  les  raisons  évoquée  ci-dessus,  il  est  souvent  bâclé  tant  dans  sa 
rédaction  (pourtant  souvent  facturée)  mais  surtout  dans  sa  lecture  et  validation  / 
acceptation  par  le  client,  qui  a  hâte  de  démarrer  son  projet 

En  lieu  et  en  place  du  cahier  des  charges  nous  faisons  un  Backlog. 


(jJtHE  GOING  TO 
TR  Y  SOMETHI1MG 
CALLED  AGILE 
PRÛGRAMMING. 


TUAT  ME  ANS  MO  MORE 
PLANNING  AND  MO  MORE 
DOCUMENTATION.  JUST 
&TAAT  WAITING  CODÉ 
AND  COMPLAlNlNG 


I  M  G  L  AD 
IT  MAS  A 
NAME. 


Le  product  Backlog  ou  "carnet  de  produit"  en  bon  français  ;-)  est  une  liste  qui  définit  les 
besoins.  Il  s'agit  d'une  liste  de  demandes  et/ou  exigences  jugées  nécessaires  pour  la  réalisation 
du  produit.  Contrairement  à  un  cahier  des  charges,  le  périmètre  fonctionnel  défini  dans  le 
product  Backlog  n'est  pas  figé  pour  toute  la  durée  du  projet.  Il  est,  par  définition,  évolutif. 
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En  fonction  de  l'état  d'avancement  du  produit,  des  difficultés  ou  autres  impondérables 
rencontrés,  vous  pourrez  décider  de  modifier  les  fonctionnalités  souhaitées,  en  revoyant  leur 
ordre  de  priorité,  voire  d'abandonner  certaines  demandes  qui  seraient  devenues  obsolètes  au 
fil  du  projet  ou  pour  y  substituer  de  nouveaux  besoins  plus  importants  ou  qui  étaient 
inexistants  au  tout  début  du  projet. 

Ainsi,  au  fur  et  à  mesure,  le  périmètre  fonctionnel  du  développement  change. 

Quant  au  prestataire  il  s'engage  à  fournir  une  certaine  quantité  de  travail  de  qualité  et  à  vous 
garantir  un  certain  résultat  pour  chaque  Sprint. 

Un  Sprint  est  l'ensemble  du  travail  réalisé  pendant  une  période  relativement  courte 
(idéalement  trois  semaines)  au  bout  de  laquelle  le  prestataire  livre  un  module  ou  une  partie 
fonctionnelle  et  utilisable  du  produit. 

Le  projet  de  développement  du  produit  est  donc  "découpé"  en  Sprints  qui  constituent  autant 
de  sous-projets  (ou  modules  du  produit)  nécessaires  au  développement  complet  du  produit. 

Chaque  Sprint  est  donc  un  mini-mandat  avec  un  périmètre  limité.  Chaque  Sprint  a  une  date  de 
début  et  de  fin,  et  aboutit  à  un  résultat  concret  (module  du  produit)  fonctionnel  et  utilisable. 

Au  début  de  chaque  Sprint,  le  prestataire  et  le  mandant  définissent  ensemble  quelles  sont  les 
demandes/fonctionnalités  qui  seront  réalisées  au  sein  du  Sprint. 

La  brièveté  du  Sprint  minimise  les  écueils  rencontrés  lors  de  longs  projets  au  forfait  et  permet 
de  faire  toujours  mieux,  Sprint  après  Sprint,  puisque  chaque  Sprint  est  un  mini-mandat  qui 
permet  de  capitaliser  en  communication,  compréhension,  attentes  et  donc  en  qualité  globale. 

Les  relations  avec  vous  reposent  sur  une  bonne  collaboration  et  non  sur  un  cahier  des  charges 
rigides  posé  par  écrit. 

Avec  cette  méthode  agile  (par  Sprints)  on  avance  très  rapidement  et  obtient  les  premiers 
résultats  concrets  en  quelques  semaines...  plutôt  qu'en  de  nombreux  mois! 

Vous  restez  libre  de  suivre  l'évolution  des  choses  et  de  gérez  vous-même  votre  budget. 
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✓^llne  faut  pas  contraindre  les 
[  développeurs,  ni  le  plannins,  il  faut  ' 
\se  libérer  et  s'adapter  pour  obtenir  J 
un  vrai  bon  produit  ! 


b  er 


or  m 


SUIS 


d'entendre 


son 


♦ .. 


S* 


rares 


f  -ents 


or  r  a 


vraiment 


philosophie 


Par  contre,  niveau  budget, 
vous  me  ferez  une  estimation 
3lobale  au  forfait,  j'ai  besoin  d’avoir 
de  la  visibilité,  vous  comprenez 


CommitStnp.com 


Le  modèle  waterfdll.  c’est  obsolète!^ 
L’heure  est  à  l'écoute  des  utilisateurs, 
aux  sprints  courts  et  aux  itérations 


/Cec^u'il  me  faut.  c’estdeN 
VJViQilité  et  de  la  flexibilité 


À  chaque  Sprint,  le  mandant  sait  précisément  ce  qui  a  été  développé  et  ce  qui  reste  à  faire,  et 
quel  budget  a  été  consommé.  Ces  indicateurs  permettant  de  décider  sur  les  "petits  détails"  et 
de  décider  au  fur  et  à  mesure  des  fonctionnalités  que  vous  souhaitez  intégrer,  selon  vos 
priorités  du  moment  et  selon  l'usage  réel  que  vous  faites  de  votre  logiciel,  dans  la  pratique  et 
selon  les  retours  des  vrais  utilisateurs. 


Avantages  Agile 

Désavantages  Agile 

Pas  de  temps  consacré  au  cahier  des  charges 

Il  faut  de  bons  communicants 

Bien  adapté  aux  petits  projets,  sans  normes, 
sans  criticité 

Il  faut  du  temps  disponible  pour  faire  les 
sprints  (car  souvent  plus  long  en  cumulé 
qu'un  cahier  des  charges) 

Meilleur  contrôle  des  coûts  pour  le  client 

Il  faut  un  client  d'accord  de  payer  par  petites 
factures  successives  mensuelles 

Plus  grande  flexibilité  pour  le  client 

Il  faut  une  direction  d'accord  de  faire  payer  le 
client  par  petites  factures  successives 

Minimisation  des  risques  pour  le  client 

Accroissement  des  e-mails  et  de 
l'administration  qui  a  un  coût  significatif. 

Meilleure  analyse  de  l'évaluation  du  projet 

Le  produit  n'est  jamais  vraiment  fini  avec 

Agile  donc  difficile  de  gérer  le  temps  des 
développeurs  sur  d'autres  projets. 

Évolution  plus  logique  du  produit  (pas  de 
"mais  c'était  implicite". . .) 

Les  développeurs  doivent  souvent  passer  du 
coq  à  l'âne  avec  leur  code  ce  qui  n'est  pas 
agréable  du  tout. 

Maximisation  du  risque  financier  puisqu'à 
chaque  sprint  le  client  peut  arrêter  le  mandat. 

Au  jour  où  nous  écrivons  ces  lignes,  nous  avons: 
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Agile  Certified  Praticionner 

Connaissance  approfondie  et  minimum  3’500  h 
d'expérience  (Selon  niveau  d’étude) 

CV  + 
QCM 

3  ans, 

renouvellement 
par  PDU 
(Professional 
Development 
Units) 

4.19  MCTS 
Microsoft 

C  E  R  T  I  Fl  E  D 

facrtriLiiîü.gii'G 

Spaciaîist 


La  certification  Microsoft  Office  Project  et  Project  Server  est  une  certification 
professionnelle  conçue  pour  permettre  aux  professionnels  du  management  de  projet  de 
mesurer  leur  niveau  de  maîtrise  de  l'utilisation  de  Microsoft  Office  Project  et  Project  Server 
pour  l'initiation,  la  planification,  l'exécution,  la  surveillance,  la  maîtrise  et  la  clôture  des 
projets,  programmes  et  portefeuilles  de  projets. 

Cette  série  de  certifications  apporte  une  plus-value  à  la  fois  pour  les  organisations  et  pour  les 
individus  qui  pratiquent  le  Management  de  Projet  ou  qui  désirent  améliorer  leurs  compétences 
et  leurs  opportunités  de  carrière  dans  ce  domaine.  La  validation  d'un  champ  plus  vaste  de 
compétences  donne  aux  candidats,  et  à  leur  hiérarchie,  un  indicateur  de  performance  fiable. 
Cela  correspond  à  une  réelle  demande  des  clients  devant  les  besoins  croissants  en 
compétences  en  Management  de  Projet,  y  compris  dans  la  maîtrise  des  outils  associés. 

Trois  niveaux  de  certifications  sont  reconnus  à  l'international: 

1.  MCTS  MS  Project  Pro:  Assure  la  maîtrise  de  la  version  client  de  MS  Project  avec  3 
jours  de  formations. 

2.  MCTS  MS  Project  Server:  Assure  la  maîtrise  de  la  version  client  de  MS  Project  avec  3 
jours  de  formations. 

3.  MC  IT  Pro  Project  Server:  Assure  les  compétences  dans  l'installation  et  la 
maintenance  de  MS  Project  Server  pour  un  informaticien. 

Formation:  ~3  à  9  jours  selon  le  niveau  de  maîtrise  souhaité 
Niveau:  Bac  à  Bac+2 
Certification/Diplôme:  Oui 

Source:  www.  iiL  com/france/msproject/ 

4.20  EFQM 

EFOM 
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L’European  Foundation  for  Quality  Management  ou  EFQM,  (en  français:  Fondation 
Européenne  pour  le  Management  par  la  Qualité)  est  une  association  européenne  basée  à 
Bruxelles  fondée  en  1988  par  14  entreprises  avec  l’appui  de  la  commission  européenne. 

L’EFQM  compte  aujourd'hui  plus  de  700  membres.  L’objectif  de  cette  organisation  à  but  non 
lucratif  est  de  promouvoir  un  cadre  méthodologique  pour  permettre  à  ses  membres  d’évaluer 
leur  niveau  de  qualité  et  de  s’améliorer  de  façon  durable. 


Accomplir  des  résultats  équilibrés 


Prendre ses 

responsabilités  pour  un 
Futur  Durable 


Ajouter  de  la  Valeur 
pour  les  clients 


Etablir  des 

Relations 

humaines 


Modèle  EFQM 


Diriger  avec 
Vision,  Inspiration 
et  Intégration 


Faire  éclore  la 
Créativité  et 
l'Innovation 


Manager  avec  méthode 


Réussir  à  travers  les  gens 


Les  Principes  Fondamentaux 


Son  modèle  d'autoévaluation  est  fondé  sur  9  principes/processus  (qui  n’ont  pas  tous  la  même 
pondération)  de  l'évaluation  de  la  qualité  d'une  entreprise  en  termes  de  gestion. 

Elle  propose  par  la  même  occasion  un  modèle  commun  européen  très  intéressant  de  notation 
des  entreprises  que  tout  à  chacun  peut  mettre  en  pratique  pour  voir  où  son  entreprise  se  situe  à 
l'aide  d'un  barème  de  points  comprise  entre  [0,1000], 

Les  critères  de  ce  modèle  sont  (voir  schéma  ci-dessous): 

•  En  termes  de  facteurs:  le  leadership,  le  personnel,  la  politique  et  stratégie,  les 
partenariats  et  ressources  et  les  processus. 
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•  En  ternies  de  résultats:  le  personnel,  les  clients,  les  collectivités  (société),  les 
performances  clés. 


Facteurs 


Résultats 


Innovation,  Apprentissage,  Créativité 


L'EFQM  est  ce  que  l'on  appelle  un  "modèle  d'excellence"  visant  à  montrer  par  un  concours  et 
un  prix  qu'une  entreprise  est  la  meilleure  dans  son  domaine  d'activité  (parmi  ceux  appliquant 
la  méthode...).  Il  y  a  d'autres  modèles  d'excellent  amenant  aussi  à  des  prix  et  classements 
comme  le  modèle  américain  Malcolm  Baldridge  National  Quality  Award  et  le  modèle 
japonais  du  prix  Deming. 

Formation:  ~3  jours 
Niveau:  Bac 

Certification/Diplôme:  Oui 
Source:  www.efqm.org 

4.21  Dimension  4 


Dimension  4  est  une  méthodologie  regroupant  un  ensemble  de  techniques  et  d'outils  pour  la 
réalisation  de  bénéfices.  Mises  ensemble,  elles  réduisent  l'incertitude  concernant  les  résultats 
d'un  projet.  Mais  ces  techniques  peuvent  aussi  être  utilisées  séparément  pour  traiter  des 
difficultés  liées  au  projet. 

Cette  méthodologie  propose  que  chaque  changement  soit  lié  à  un  bénéfice  financier,  même 
ceux  qui  sont  obligatoires  ou  financiers. 
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Formation:  4  jours  avec  un  test  à  la  fin  de  chaque  journée 
Source:  www.isochron.co.uk 


4.22  PM2 


Le  guide  gratuit  PM2  a  été  produit  par  le  centre  d'Excellence  en  Méthodologie  de  gestion  de 


projet  de  la  Commission  européenne,  le  Centre  of  Excellence  in  Project  Management 
Methodology  (CoEPM2).  Il  est  assez  complet  dans  les  rudiments  de  la  gestion  de  projets  et 
donne  assez  d'explications  pour  une  vue  complète  de  l'approche  de  management  de  projet 
traditionnelle  (conformément  à  IS021500,  PRINCE2  et  PMP)  avec  une  saveur  de 
management  de  portefeuille  et  l'intégration  agile.  PM2  inclut  aussi  le  management  des 
bénéfices  et  le  management  de  la  transition  (comparable  avec  MSP).  Le  manuel  a  beaucoup 
d'images  colorées. 


Op*n  Project  M»n«9er«*nl 
Methodology 


Beaucoup  de  personnes  bien  intentionnées  ont  certainement  mis  beaucoup  d'énergie  dans  le 
développement  de  cette  méthodologie  PM2.  On  peut  se  demander  tout  de  même  si  nous  avions 
réellement  besoin  d'une  nouvelle  méthodologie.  Pourquoi  dépenser  tant  d’efforts  pour  une 
chose  déjà  disponible  ?  Pourquoi  un  nouveau  programme  de  certification,  pourquoi  une 
nouvelle  communauté  ?  Nous  avons  PMP,  PRINCE2,  PRINCE2  Agile,  Sérum,  MSP  et  les 
certifications  IPMA,  nous  avons  les  meilleurs  groupes  de  pratique  comme  BPUG  et  les 
communautés  IPMA  et  PMI. 

De  plus  on  peut  s'inquiéter  du  niveau  de  la  méthode  quand  on  sait  la  taille  de  certains  projets 
de  la  comission  européenne.  On  est  a  des  années  lumières  de  ce  qui  est  utilité  par  la  NASA 
par  exemple! 
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Effective 

Solutions  &  Benefits 

Delivery 

Control  &  Agility 


The  PM^ethodology  Guide 
Project  Management  Best  Practices 


Formation:  ~4  jours 
Niveau:  Bac 

Certification/Diplôme:  Oui 

Source:  https://bookshop.europa.eu/en/pm-proiect-management-methodologv-guide- 

pbNQ07 16056/ 

4.23  MBA 

MBA 

Le  Master  of  Business  Administration  ou  MBA,  est  un  diplôme  international  d'études 
supérieures  dans  le  domaine  de  la  conduite  globale  des  affaires:  stratégie,  marketing,  finances, 
ressources  humaines  et  management. 

Dans  le  modèle  traditionnel  américain,  les  étudiants  travaillent  sur  un  large  éventail  de  cours 
la  première  année,  puis  entament  une  spécialisation  lors  de  la  seconde.  Dans  le  reste  du 
monde  le  MBA  dure  en  général  moins  longtemps:  entre  9  et  16  mois  en  Europe,  l'objectif 
essentiel  étant  de  réduire  au  maximum  le  temps  passé  par  des  cadres  en  dehors  de  l'entreprise. 

Formation:  ~  65  jours 
Niveau:  Bac  à  Bac+3 
Certification/Diplôme:  Oui 

4.24  ENS 

(WS 
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L'ENS  (Ecole  Normale  Sup.)  propose  le  cursus  de  formation  en  gestion  de  projets  que  je 


considère  comme  le  plus  pointu  et  complet  à  ma  connaissance  et  à  ce  jour.  Il  s'agit  d'un 
excellent  minimum  minimorum  pour  être  ingénieur  en  gestion  de  projets  avec  un  cursus 
actuel  de  7  ans  (prérequis  inclus). 

Le  programme  est  le  suivant:  Un  cycle  de  formation  de  350  heures  environ  (soit  2  ans  à  peu 
près)  d'enseignements  techniques,  théoriques  et  pratiques  sous  forme  de  modules  spécialisés 
(22  modules):  finance  d'entreprise,  analyse  et  prévision  financière,  macro-économie 
financière,  finance  empirique,  évaluation  des  entreprises,  fusions  et  acquisitions,  techniques 
financières  internationales,  gestion  de  portefeuille,  gestion  des  risques  bancaires,  taux  et 
produits  dérivés  de  taux,  risque  de  crédit  et  produits  dérivés  de  crédit,  introduction  aux 
processus  stochastiques  en  temps  continu,  méthodologie  informatique,  calcul  stochastique 
pour  la  finance,  évaluation  et  couverture  des  produits  dérivés,  résolution  numérique  des  EDP 
pour  la  finance,  économétrie  des  séries  temporelles  et  modèles  ARCH  en  finance,  statistique 
des  processus  en  finance,  méthodes  neuronales  et  applications  financières,  microstructure  et 
organisation  des  marchés,  gestion  des  risques  de  l'entreprise,  finance  d'entreprise  approfondie, 
simulation  salle  des  marchés,  développement  informatiques,  suivi  des  projets. 

Cette  solide  formation  appliquée  est  complétée  par  une  thèse  professionnelle  validant  un 
projet  de  4  à  6  mois  en  entreprise. 

Le  public  visé  est  des  ingénieurs  diplômés,  diplômés  d'Écoles  de  gestion  dont  le  titre  est 
reconnu  par  la  Conférence  des  Grandes  Ecoles,  ou  titulaires  d'un  DEA  ou  d'un  DESS  dans  les 
disciplines  suivantes:  mathématiques,  mathématiques  appliquées,  sciences  physiques,  gestion 
et  sciences  économiques  (options  économétrie,  économie  mathématique,  finance 
quantitative...)  ou  titulaires  d'un  diplôme  étranger  de  type  Master  of  Science  ou  diplôme 
équivalent. 

Formation:  ~60  jours 
Niveau:  Bac+4  à  Bac+7 
Certification/Diplôme:  Oui 


r 


KEEP  

SIMPLE!  V 


N 


V  # 
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5.  Logiciels 


Photosrapher 
with  his  caméra 


Project  manager 
with  his  computer 


CommitStrip.com 


Pour  travailler  dans  le  domaine  de  la  gestion  de  projets,  de  la  qualité,  de  la  finance  et  des 
risques,  les  logiciels  les  plus  connus  et  utilisés  (ce  qui  ne  veut  pas  forcément  dire  que  ce  sont 
les  meilleurs. . .)  considérés  souvent  comme  les  outils  minimum  que  doit  posséder  un 
responsable  de  projet  sont  les  suivants.  Cependant,  la  connaissance  de  cette  liste  ne  doit  pas 
amener  le  responsable  de  projet  à  se  soustraire  à  la  norme  ISO  9241-1 1  qui  permet  de  vérifier 
"le  degré  selon  lequel  un  produit  peut  être  utilisé,  par  des  utilisateurs  identifiés,  pour 
atteindre  des  buts  définis  avec  efficacité,  efficience  et  satisfaction,  dans  un  contexte 
d'utilisation  spécifié".  Car  entre  les  (soi-disant)  responsables  de  projets  dans  les 
multinationales  qui  utilisent  un  tableur  pour  faire  des  planning  est  de  pseudo  "bases  de 
données"  et  ceux  qui  ont  des  logiciels  de  gestion  de  projets  qui  buggent  complètement  car  ils 
n'ont  pas  attendu  le  service  pack  2  ou  3  il  y  a  un  laxisme  général  à  faire  grimper  les  experts 
aux  rideaux... 


Enfin,  rappelons  que  selon  le  BABOK,  le  business  analyst  et  donc  aussi  un  peu  le 
coordinateur  de  projets  devraient  choisir  les  méthodes  et  outils  de  gestion  en  fonction  de  la 
disponibilité  des  outils,  de  leurs  limitations,  des  standards  organisationnels,  des  contraintes 
temporelles  et  du  budget. 


MdnoAOmtt 

du  Project 

ZfiWpt «  PfGÎML 


Inutile  de  revenir  sur  une  description  de  Microsoft  Office  Project,  car  il  s'agit  du  sujet 
principal  auquel  prépare  ce  support  (et  voir  mon  livre  de  -900  pages  sur  ce  logiciel).  Le 
responsable  de  projet  ne  doit  simplement  pas  oublier  qu'il  existe  à  ce  jour  trois  versions 


Ingénierie  de  Gestion  de  projets 


85/547 


Vincent  ISOZ 


différentes  de  ce  produit  (Standard,  Pro  et  Server)  et  qu'il  faut  au  minimum  5  à  8  jours  de 
formations  pour  maîtriser  les  bases  de  l'outil  (ce  qui  ne  prend  donc  pas  en  compte  la  durée  de 
formation  pour  les  bases  en  gestion  de  projets!). 

Open 

Proj 

OpenProj  est  un  outil  de  planification  de  projet  gratuit.  Le  logiciel  permet  la  planification  de 
tâches  avec  association  de  dépendances,  de  ressources,  et  un  état  d'avancement  ou  une 
catégorie.  OpenProj  est  un  clone  de  Microsoft  Project,  il  permet  de  lire  et  modifier  les  fichiers 
de  ce  dernir. 

[U  Microsoft'  Office 

□a  Sha  rePoint 

L'outil  web  par  excellence  pour  une  gestion  professionnelle  de  la  communication  et  de  la 
gestion  des  documents  et  workflows  dans  le  cadre  des  projets  ou  de  la  qualité.  C'est  un  outil 
de  toute  manière  obligatoire  si  l'on  souhaite  posséder  Microsoft  Project  Server. 

B  Q  *1  Microsoft  Office 

□□.Visio 

Outil  de  référence  mondiale  en  bureautique  classique  pour  modéliser,  formaliser  et 
dématérialiser  les  processus  d'une  entreprise  en  conformité  avec  ISO  5807:85  ou  la  B.P.M.N. 
dans  le  cadre  de  ses  projets  ou  de  sa  gestion  de  la  qualité  et  des  flux  d'informations. 

Microsoft  Office 

y  a  Word 

Connu  par  tout  le  monde  mais  bien  évidemment  indispensable  pour  rédiger  des  cahiers  des 
charges  ou  plans  directeurs  de  projets  correctement  et  conformément  aux  normes  en  vigueur 
(je  ne  vais  pas  ici  discuter  de  la  comparaison  avec  LaTeX. . .). 

Micfosotl  Office 

Cil  Excel 

Connu  par  tout  le  monde  et  utilisé  même  par  des  financiers  et  responsables  de  projet  de  très 
très  haut  niveau  malgré  ses  faiblesses  en  statistiques  avancées.  Comme  de  nombreux  add-ins 
payant  s'y  greffent  de  toute  manière,  il  reste  un  outil  de  référence  pour  l'analyse  des  projets  et 
de  la  qualité,  ainsi  que  la  modélisation  statistique  et  l'optimisation. 

MitrCi^t  Office 

□□Outlook 

Connu  aussi  de  tous  ce  logiciel  de  messagerie  est  indispensable  depuis  la  fin  de  20eme  siècle 
pour  communiquer  avec  les  clients.  Il  est  surtout  important  dans  le  cadre  de  la  gestion  de 


Ingénierie  de  Gestion  de  projets 


86/547 


projets,  car  son  agenda  se  connecte  à  MS  Project  Server  pour  les  ressources  et  à  SharePoint 
pour  prendre  les  documents  en  itinérance. 

■  ^1  Microsoft  Office 

cia  OneNote 

Microsoft  Office  OneNote  est  un  logiciel  collaboratif  ou  individuel  de  prise  de  note  et  de 
gestion  déstructurée  de  l'information  extrêmement  utile  pour  les  cadres  noyés  sous 
l'information  et  permettant  outre  une  organisation  rapide  de  l'info  et  de  gérer  les  notes  de 
réunions  rapidement  de  faire  de  la  recherche  OCR  de  texte  dans  les  images  et  de  synchroniser 
la  capture  son  ou  vidéo  des  réunions  avec  les  pris  de  notes  textuelles. 

Minitab^ 

Stadstlcal  Software 

Outil  très  utile  pour  simplifier  l'analyse  de  données  dans  le  domaine  de  la  qualité,  de  la 
gestion  de  projets  et  même  de  la  R&D  (mais  ça  c'est  hors  sujet  dans  ce  support).  On  peut  faire 
(pour  les  usages  courants)  le  même  travail  dans  MS  Excel,  mais  cela  prend  beaucoup  plus  de 
temps  et  nécessite  quasiment  systématique  le  recours  à  la  programmation  VBA. 


Le  meilleur  (sans  aucun  doute!)  outil  du  marché  dans  la  modélisation  statistique  (Monte- 
Carlo,  Latin-Hypercube)  de  l'aide  à  la  décision  pour  la  durée,  les  coûts  ou  les  risques  de 
projets.  C'est  un  des  logiciels  de  référence  des  top  managers  quantitatifs. 

TreeAge 

3DITWUE.  INC 


Le  seul  logiciel  à  ma  connaissance  qui  permette  de  créer  des  modèles  d'arbres  de  décisions  et 
de  Markov  pour  l'aide  à  la  décision.  Il  permet  aussi  d'intégrer  des  statistiques  simples  ou  des 
modèles  de  fonctions  de  probabilités. 

isograph 

•••• 


Pour  l'instant  c'est  à  mon  goût  le  logiciel  le  plus  complet  pour  faire  des  arbres  d'événements, 
des  arbres  de  décision,  des  arbres  de  défaillance  probabilistes  (associé  à  de  l'AMDEC  avec 
Monte-Carlo). 


ap2msp 
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Permet  d'aider  à  appliquer  la  méthode  de  management  Prince2  dans  le  cadre  de  la  gestion  de 
projets  avec  MS  Project  comme  la  description  et  le  suivi  des  produits,  risques,  requêtes  et 
clients  dans  MS  Project  et  de  pouvoir  les  gréer  entre  plusieurs  fichiers. 


Excellents  logiciels  pour  l'analyse  (statistique  et  graphique)  et  le  suivi  des  risques  selon  de 
nombreuses  normes  techniques,  médicales,  mécaniques,  ISO,  AMDEC. 

3J 

EftV  krtfl™tx™i 

Excellente  solution  intégrée  à  SAP  pour  faire  de  l'AMDEC,  du  FMEA  et  presque  tout  ce  qui 
est  relatif  à  la  gestion  de  la  qualité.  Un  bijou  à  priori! 


W 


La  référence  pour  prendre  des  notes  rapidement  lors  de  réunions  internes  ou  clientèles  et 
modéliser  simplement  des  concepts  ou  idées  dans  des  situations  normales  ou  critiques. 


CREATIVE  DECISIONS 
FOUNDATION 

Pç-clsfara  Mailing  wllfr  D^prndcncr  and  F  ui'db-ick 


Logiciel  permettant  de  mettre  en  place  la  technique  décisionnelle  quantitative  APH  basée  sur 
les  valeurs  propres  démontrée  dans  le  cours  théorique  de  mathématique  décisionnelle. 

Il  est  par  ailleurs  conseillé  comme  l'exige  ISO  9001  que  la  liste  des  logiciels  autorisés  et 
officiels  soit  documenté  et  que  les  employés  soient  bien  informés  de  l'existence  de  cette  liste. 
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6.  Documents  (modèles) 

Le  responsable  de  projet  a  besoin  d'une  boîte  à  outils  dans  le  cadre  de  son  travail 
(normalement  mis  à  disposition  et  créés  par  les  Business  Analyst  selon  le  BABOK).  Nous 
avons  déjà  certes  au  début  de  ce  support  présenté  quelques  logiciels  et  méthodologies. . .  mais 
il  faut  aussi  si  possible  des  modèles  de  documents  qui  vont  avec  et  qui  pourront 
éventuellement  lui  faire  gagner  un  peu  de  temps  sur  l'élaboration  de  ses  propres  modèles 
"corporate".  Posséder  des  modèles  de  documents  (bref  un  fond  documentaire  solide!)  est  aussi 
important  car  dans  de  nombreux  domaines  de  l'économie  la  règle  suivante  s'applique: 

Ce  qui  n'a  pas  été  documenté  n'a  pas  été  fait! 

Nous  supposerons  à  ce  titre  que  tout  à  chacun  possède:  MS  Word,  MS  Excel,  MS  Project, 

MS  Visio  puisqu'ils  contiennent  depuis  2010  (surtout  les  2  derniers)  des  modèles  très 
intéressants  et  presque  finalisés  en  ce  qui  concerne  l'application  de  la  BPMN,  TQM  et 
Six  Sigma. 

Nous  fournissons  aux  participants  à  la  formation  les  modèles  suivants,  servant  de  base  à  une 
première  réflexion,  que  nous  allons  ouvrir  et  analyser  en  groupe  tout  au  long  de  la  lecture  de 
ce  support: 

-  AccidentFRVl_0.dot  (2  pages  A4):  un  fichier  MS  Word  permettant  d'afficher  les 
accidents/anomalies  ayant  eu  lieu  dans  le  cadre  d'un  projet  ou  d'un  centre  de  production 
dans  les  couloirs  de  l'entreprise  ou  sur  le  mur  d'un  bureau  pour  tous. 

-  AMDECFRV2_0.xlt:  un  fichier  MS  Excel  permettant  de  faire  une  analyse  et  un  suivi 
selon  les  méthodes  qualitatives  AMDE(C). 

-  AnomalieQualiteFRVl_0.dot  (1  page  A4):  un  fichier  MS  Word  (à  défaut  d'une  base  de 
données. . .)  utilisable  comme  base  de  travail  pour  le  suivi  des  anomalies  qualité  et  donc  de 
non  respects  des  processus. 

-  BuinessPlanFRVl_0.dot  (24  pages  A4):  un  fichier  MS  Word  structuré  contenant  la 
structure,  la  table  des  matières  et  les  différents  chapitres  nécessaires  à  l'élaboration  d'un 
Business  Plan  digne  de  ce  nom. 

-  CahierDesChargesFRV4_0.dot  (34  pages  A4):  un  fichier  MS  Word  contenant  la 
structure,  la  table  des  matières  et  les  différents  chapitres  nécessaires  à  l'élaboration  d'un 
cahier  des  charges  (CdC)  et  d'un  plan  directeur  de  projet7  (PdP)  professionnel  très 
complet  8(Project  Management  Plan).  Ce  type  de  fichier  évolue  tout  le  long  du  projet 
jusqu'à  sa  clôture  définitive  (certains  préfèrent  faire  évoluer  uniquement  le  PdP). 

-  ConditionsGeneralesFRVl_0.dot  (11  pages  A4):  un  fichier  MS  Word  contenant  les 
grandes  lignes  des  conditions  générales  d'un  contrat  pour  un  projet,  une  vente  de  service 
ou  de  produit. 


7  Appelé  aussi  parfois  "Note  de  cadrage" 

8  De  plus  en  plus  d'entreprise  intègre  le  dossier  de  spécification  dans  le  CdD  bien  que  cela  ait  tendance  à  alourdir 
considérablement  le  document 
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-  AppelOffreFRVl_0.dot  (6  pages  A4):  un  fichier  MS  Word  contenant  les  grandes  lignes 
d'un  appel  d'offre  à  candidatures  typique  ("request  for  bid"  ou  "request  for  proposai"9) 

-  ChangeRequestFRVl_0.dot  (1  page  A4):  toute  demande  de  changement  de  directive, 
d'ajout  de  tâche  ou  de  correction  dans  un  projet  qui  changera  la  configuration  du  livrable 
doit  être  faite  par  le  client  (interne  ou  externe)  selon  une  procédure  et  une  mise  en  forme 
standardisée  nécessitant  un  minimum  de  temps.  C'est  ce  que  propose  ce  document.  Ce 
document  sera  aussi  utilisé  pour  les  "service  request"  (demande  qui  n'implique  pas  de 
changer  la  configuration  du  livrable). 

-  CodeDeConduiteReunionsFRVl_0.dot  (1  page  A4):  contient  les  règles  de  conduite  et 
de  préparation  à  mettre  sur  le  mur  de  vos  salles  de  réunions. 

-  Procès  VerbalReunionsFRVl_0.dot  (1  page  A4):  contient  les  informations  minimales 
pour  un  process  verbal  correct. 

-  DashboardFRVl_0.xlt:  un  modèle  MS  Excel  contenant  un  vieux  et  simple  tableau  de 
bord  avec  des  indicateurs  de  performance  sous  différents  aspects. 

-  EFQMSelfAssessmentENVl_0.xlt:  un  modèle  MS  Excel  permettant  de  faire  un  bilan 
qualitatif  de  son  entreprise  suivant  le  standard  EFQM.  Je  n'ai  pas  encore  créé  le  modèle 
permettant  de  faire  le  bilan  selon  la  pondération  quantitative  de  ce  standard.  Il  faudra  donc 
patienter. 

-  GanttFRV  1  O.mpt:  un  modèle  MS  Project  de  base  pour  les  plannings  (modélisation 
déterministe  de  la  durée  et  coût  d'un  projet)  un  peu  amélioré  par  rapport  à  ce  que  propose 
le  logiciel  par  défaut.  Ce  fichier  est  amélioré  (comme  tous  les  autres)  à  chaque  formation 
selon  les  remarques  des  participants. 

-  GroupesFRVl_0.xlt:  Tableau  MS  Excel  aidant  à  définir  des  groupes  et  membres 
d'équipes  de  projet  avec  leurs  niveaux  de  délégation  et  rôles  respectifs. 

-  IS09001ManagementReviewENVl_0.mpt  (56  tâches):  un  modèle  MS  Project  avec  le 
planning  et  la  charge  des  ressources  nécessaires  à  la  préparation  d'un  audit  pour  l'ISO 
9001  tels  qu'utilisé  en  Grande-Bretagne  ou  dans  de  nombreux  payse  de  l'Union 
Européenne. 

-  ISO5807FR  .vss  (27  primitives):  un  modèle  de  gabarit  MS  Visio  que  j'ai  personnalisé  et 
complété  afin  d'être  conforme  au  plus  proche  au  standard  ISO  5807:1985. 

-  ProcessusFRV5_0.vst:  un  modèle  MS  Visio  avec  les  gabarits  les  plus  courants  déjà 
ouverts  ainsi  qu'une  mise  en  page  conforme  aux  standards  ISO  et  Six  Sigma  et  des 
propriétés  de  formes  suffisamment  complètes  dans  un  schéma  de  propriétés  enregistré  à 
même  dans  le  document  sous  le  nom  Template  Set  +  71  processus  déjà  faits  couvrant  de 
nombreux  départements  d'entreprise  (150  pages  A4). 


9  La  différence  entre  "request  for  bid"  et  "request  for  proposai"  est  que  le  premier  va  se  baser  sur  un  sélection 
dont  le  seul  critère  sera  le  prix  alors  que  le  deuxième  prendra  en  considération  d'autres  facteurs. 
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-  MatriceAnalyseHOQENVl_0.xlt:  mise  à  disposition  par  une  société  américaine,  ce 
modèle  MS  Excel  propose  une  House  Of  Quality  Six  Sigma  assez  élaborée  et  servira  donc 
de  base  à  une  analyse  qualitative  de  la  corrélation  et  des  facteurs  entre  les  contraintes 
internes  (VOP)  et  les  exigences  du  client  (VOC).  Ce  modèle  peut  également  être  utilisé 
comme  outil  d'aide  à  la  décision  pour  analyser  les  réponses  à  un  appel  d'offres. 

-  SixSigmaDMAICCycleENVl_0.mpt  (36  tâches):  un  modèle  MS  Project  avec  le 
planning  et  les  phases  correspondantes  pour  la  mise  en  place  d'un  projet  Six  Sigma  selon 
l'approche  DMAIC. 

-  OffreEmploiFRVl_0.dot  (2  pages  A4):  un  modèle  MS  Word  pour  publier  une  offre 
d'emploi  standardisée  et  complète  afin  d'engager  des  ressources  pour  un  projet  (et  surtout 
afin  d'éviter  l'amateurisme  général  actuel  du  niveau  de  détail  des  offres  d'emploi  visible 
sur  le  marché) 

-  HERMESFRVl_0.mpt  (461  tâches):  un  modèle  MS  Project  avec  le  planning  et  les 
phases  correspondantes  pour  la  mise  en  place  d'un  projet  Hermès  "avancé". 

-  PRINCE2ENVl_0.mpt  (46  tâches):  un  modèle  MS  Project  avec  le  planning  et  les  phases 
correspondantes  pour  la  mise  en  place  d'un  projet  selon  PRINCE2. 

-  PMIENVl_0.mpt  (49  tâches):  un  modèle  MS  Project  avec  le  planning  et  les  phases 
correspondantes  pour  la  mise  en  place  d'un  projet  selon  le  PMBOK  du  PMI. 

Et  plutôt  que  de  recréer  la  roue  dans  de  nombreux  domaines,  le  lecteur  aura  accès  pour  une 

somme  modeste  à  quantité  de  documents  déjà  existants  (en  français,  anglais  et  allemand): 

http://www.biztree.com 

plus  des  affiches  (posters)  imposés  par  la  loi  dans  de  nombreux  pays  sur  le  site  suivant  pour 

une  somme  négligeable: 


http://www.affichage-obligatoire-pro.fr 

Remarque:  Rappelons  que  tout  changement  sur  un  document  (modèle  ou  pas!)  doit  être 
évalué  (contrôlé),  approuvé  et  mis  en  place  et  que  les  modifications/corrections  doivent  être 
datées  et  signées  et  la  raison  de  la  modification  noté.  Par  ailleurs  on  doit  toujours  avoir  une 
traçabilité  des  changements  via  un  système  de  versions. 

!  Suivre  les  règles  de  BPD  -  Bonnes  Pratiques  de  documentation! 
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7.  Processus  et  représentatives 


Le  responsable  de  projet  est  très  souvent  confronté  à  l'obligation  (nécessité)  de  devoir 
formaliser  des  synoptiques10  de  méthodes  de  travail  sous  forme  de  procédures  opérationnelles 
standard  (POS),  des  concepts  d'organisation  ou  des  idées.  Effectivement,  la  majorité  des 
employés  ont  besoin  d'un  système  de  référence  rigoureux  pour  la  maîtrise  collective  de  leurs 
activités  professionnelles  et  les  entreprises  dans  le  cadre  concurrentiel  du  21eme  siècle  ont 
besoin  de  processus  pour: 

•  maîtriser  les  coûts 

•  proposer  un  produit  irréprochable 

•  avoir  un  temps  de  réponse  court  et  fiable 

•  atteindre  un  résultat  de  façon  standardisée  et  fiable 

•  réduire  le  temps  et  les  coûts  de  formation 

•  adapter  ses  produits  aux  besoins 

•  appliquer  les  bonnes  pratiques  de  fabrication/travail  (voir  page  70) 

•  ne  pas  répéter  les  erreurs  du  passé  et  utiliser  le  retour  sur  expérience 

•  (obtenir  des  papiers  de  certifications  qualité...) 

et  vont  pour  cela  utiliser  typiquement  le  processus  série  récursif  d'implémentation  qui  consiste 
à: 

1.  Audit  de  l'existant  (par  du  "job  shadowing* 11") 

2.  Identification  des  objectifs  et  besoins 

3.  Description  des  processus  et  procédures 

4.  Validation  par  tous  les  intervenants 

5.  Documenter  le  système  qualité 


10  Un  synoptique  désigne  une  présentation,  en  général  graphique,  qui  permet  de  saisir  d'un  seul  coup  d'œil  un 
ensemble  d'informations  liées  ou  un  système  complexe. 

11  II  s'agit  d'observer  les  collaborateurs  faire  leur  travail  pendant  qu'ils  suivent  les  processus  internes  existants 
tout  en  se  mettant  en  retrait  et  en  notant  les  points  faibles  de  ces  mêmes  processus. 
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6.  Application  des  processus  et  procédure 

7.  Gestion  des  enregistrements 

8.  Piloter  les  changements  et  retours 

9.  Surveiller  la  capabilité 

10.  Revues 

L'approche  processus  est  donc  une  méthode  (certains  diront  une  idéologie  voire  même  une 
utopie....)  d'analyse  ou  de  modélisation  (formalisation)  qui  consiste  à  décrire  de  façon 
méthodique  une  organisation  ou  une  activité  dans  le  but  d'agir  efficacement  dessus  à 
différents  niveaux  (cartographie/méta-processus  et  processus)  et  correspond  à  une 
organisation  de  niveau  de  maturité  au  minimum  2  selon  l'échelle  du  CMMi  (voir  page  61).  Le 
processus  est  donc  essentiellement  un  outil  d'optimisation  de  la  performance  (on  devrait  plutôt 
parler  de  "rigueur"  en  réalité!).  Souvent  cette  démarche  si  elle  est  faite  sur  le  tard  consiste  à 
reconstruire  toute  l'organisation  de  l'entreprise  en  partant  quasiment  de  zéro.  Cependant  les 
résultats  sont  généralement  bons  et  ont  prouvé  l'intérêt  de  la  démarche  même  si  elle  produit 
quelques  licenciements  suite  à  l'identification  de  postes  ou  tâches  inutiles. 

Ainsi,  le  BABOK  (Business  Analysis  Body  of  Knowledge)  recommande  particulièrement  la 
mise  en  place  de  processus  lorsque  qu'une  grande  structure  fait  appel  à  de  nombreux 
prestataires  de  services  externes  et  ce  afin  d'homogénéiser  et  rationaliser  les  techniques  de 
gestion  de  leurs  méthodes  de  travail  et  de  communication. 

Certains  spécialistes  disant  que  le  rôle  des  processus  et  de  leurs  procédures  (instructions) 
associées  n'est  pas  en  plus  de  remplacer  de  pouvoir  remplacer  compétence  si  besoin  est  mais 
de  la  compléter.  Évidemment  c'est  un  point  de  vue...  en  ce  qui  me  concerne  quand  je  vois 
avec  mes  dix  années  d'expérience  de  consultant  en  entreprise  que  moins  de  2  à  3%  des  gens 
utilisent  vraiment  leur  cerveau  je  m'interroge...  (le  reste  des  97  à  98%  ayant  beaucoup  de 
peine  à  utiliser  des  raisonnements  hypothético-déductifs  qui  sont  du  niveau  du  baccalauréat). 

Remarque:  La  norme  ISO  9001:2008  n'exige  (malheureusement)  pas  de  représenter  vos 
processus  graphiquement  et  ce  même  en  respectant  leur  propre  norme  (ISO  5807:85).  Cette 
norme  n'impose  jamais  un  moyen  précis,  mais  décrit  plutôt  à  un  but  à  atteindre  (d'où  selon 
moi  le  foutoir  général  dans  la  communication  interentreprises  et  le  fait  que  tout  le  monde  ou 
presque  réinvente  la  roue).  Elle  précise  uniquement  qu'il  faut  identifier  les  processus 
nécessaires  au  système  de  management  et  de  la  qualité  [...et]  déterminer  la  séquence  et 
l'interaction  des  processus. 

Signalons  que  nombre  de  grands  comptes  qui  n'avaient  pas  de  processus  (et  leurs  procédures 
associées)  s'en  sont  mordu  les  doigts  de  l'acquisition  de  solution  ERP  dans  le  but  de 
rationaliser  la  complexité  administrative  et  de  cohérence  de  la  gestion  de  l'information! 


Ingénierie  de  Gestion  de  projets 


93/547 


Vincent  ISOZ 


Définitions  préalables  selon  ISO  9001:2008: 


Une  procédure  est  définie  comme  une  manière  spécifiée  d'effectuer  une  activité  ou  un 
processus.  La  procédure  est  donc  une  manière  défaire  qui  ne  fait  pas  obligatoirement  l'objet 
d'une  documentation.  Lorsqu'une  procédure  fait  l'objet  de  documents,  les  termes  "procédure 
écrite"  ou  "procédure  documentée"  sont  fréquemment  utilisés. 

Un  processus  est  un  ensemble  d'activités  corrélées  ou  interactives  qui  transforme  des 
éléments  d'entrée  en  éléments  de  sortie. 
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7.1.1  Objectifs 

Les  raisons  à  ces  besoins  de  formalisation  sont  relativement  simples  et  peuvent  se  résumer 
aux  quelques  points  principaux  (valeurs  ajoutées)  suivants: 

1.  Éviter  le  "management  par  exception"  (contraire  au  Six  Sigma) 

2.  Standardiser  les  actions  et  structurer  l'information  au  sein  d'un  groupe  de  travail 

3.  Garantir  une  répétabilité  à  l'identique  (mieux  répondre  aux  besoins  des  clients) 

4.  Servir  de  base  pour  les  formations  aux  méthodes  de  travail  corporate  (internes) 

5.  Faciliter  la  communication  des  méthodes  standardisées  et  les  attentes  de  résultats 

6.  Ne  pas  recréer  la  roue  à  chaque  fois  (et  ainsi  pouvoir  se  concentre  sur  l'innovation) 

7.  Formaliser  le  REX  (Retour  d'Expérience)  afin  d'éviter  des  erreurs  passées 

8.  Minimiser  les  efforts  et  le  temps  en  analysant  les  étapes  inutiles  (temps  de  passage) 

9.  Identifier,  mesurer  et  anticiper  les  problèmes 

10.  Réagir  de  manière  appropriée  et  standardisée  lors  d'imprévus 

11.  Assurer  une  traçabilité 

12.  Éviter  les  "je  savais  pas",  "tu  me  l'avais  pas  dit  donc  c'est  de  ta  faute" 

13.  Identifier  les  actions  inutiles  ou  optimisables  plus  facilement 

14.  (obtenir  des  certifications  qualité...) 

De  plus,  la  culture  processus  est  davantage,  par  son  formalisme,  une  culture  de  l'écrit  qu'une 
culture  de  l'oral.  Ainsi,  la  communication  orale  n'est  pas  interdite...  mais  il  vaut  mieux  fixer 
des  règles  admises  par  écrit  (et  les  améliorer)  plutôt  que  de  les  discuter  à  chaque  fois.  L'écrit 
(sous  forme  de  processus  et  procédures)  oblige  à  la  réflexion,  permet  l'homogénéisation,  la 
mémorisation  et  la  vérification  de  l'information,  devient  une  référence  pouvant  être  facilement 
diffusée,  autorise,  le  classement  et  l'archivage  des  informations  (le  bon  document  au  bon 
endroit). 
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Niveau  stratégique 
Référence  système 


Description  du  système 
qualité: 

POURQUOI,  QUI  est 
responsable  de 
QUOI 


Niveau  opérationnel  /  T  .  ,  ^  U1.  . 

T  .  ,  /  Instructions  de  travail  obligatoires 

Instructions  opératoires  /  /x,.  ,  ,  ,  .  ,  ,  .  . 

^  /  (fiches  techniques,  modes  opératoires) 


Instructions  de  travail 
détaillées 


COMMENT  faire  avec 
QUOI  et  QUI? 


Niveau  individuel 


Documents  personnels 


Documents  créées  et 
gérés  par  les 
collaborateurs 


Figure  5  Cinq  niveaux  de  la  hiérarchie  des  documents  qualité  (pyramide) 

Le  schéma  suivant  est  parfois  résumé  sous  la  forme  suivante: 


Hiérarchie  des  processus  dans  le  modèle  classique 


Domaines/carte  des  processus 


Activités/consignes  de  travail 


Manager  par  les  processus  est  aussi  un  préalable  à  toute  forme  de  management.  Cela  consiste 
à  connaître  toutes  les  activités  nécessaires  à  la  production  des  prestations  satisfaisantes  pour 
les  clients  et  à  en  harmoniser  le  fonctionnement.  À  cette  fin,  il  faut  identifier  les  processus, 
définir  les  règles  relationnelles,  maîtriser  les  activités  internes  à  chaque  processus  et  améliorer 
en  permanence  le  mode  de  fonctionnement  de  l'ensemble. 

Le  logiciel  le  plus  utilisé  à  travers  le  monde  à  ce  jour  et  à  notre  connaissance  (ce  qui  ne  veut 
pas  dire  que  c'est  le  meilleur!)  pour  cela  est  Microsoft  Office  Visio  qui  permet  non  seulement 
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de  faire  de  nombreux  types  de  synoptiques  mais  aussi  de  les  analyser  statistiquement  avec  des 
rapports  automatisés  d'avancement  envoyés  vers  Microsoft  Office  Excel,  de  connecter 
certaines  informations  à  une  base  de  données  centralisée,  d'afficher  des  indicateurs  de 
performances  et  au  final  (point  le  plus  apprécié)  de  publier  le  tout  sous  forme  de  pages  web 
afin  de  rendre  les  schémas  interactifs  (liens  entre  processus,  vers  des  documents,  moteur  de 
recherche,. . .).  Il  existe  cependant  nombre  de  logiciels  plus  performants  (MEGA,  Bizagi, 
Bonitasoft,  etc.). 

Si  vous  souhaitez  représenter  graphiquement  les  processus  de  votre  organisation,  commencez 
par  remplir,  sur  la  base  de  la  hiérarchie  des  processus,  la  carte  des  processus  au  niveau  le  plus 
élevé  de  votre  architecture.  Cette  carte  donne  un  aperçu  de  tous  les  processus  d'affaires  de 
votre  entreprise  et  en  illustre  les  interdépendances.  Vous  pouvez  vous  inspirer  de  l'illustration 
suivante: 


Carte  des  processus  typique 


10  Processu  s  de  gestion 


1  1  Définition  \ 

1  1  2  Planification.  1 

Bl3Gesfion  V 

[  1  4  Communication  V 

de  la  straléij  iejf 

|  budgétisation  J 

F  |  et  :  "  ota  ge 

|  interne  / 

20  Processus  do  renouvellement 

23  Gestion 

\  |  25  Marketing  &  \ 

des  produits 

#1  communication  J 

21  Gestion  de 
portefeuille 


) 


22  Développement 
de  produits  et  service:  j 


24  Gestion  de  la  distribution  et 
des  partenaires  de  service 


Vous  pouvez  donc  au  deuxième  niveau  de  votre  architecture  représenter  les  différents 
processus  d'affaires  avec  les  processus  de  travail  correspondants.  L'exemple  ci-dessous 
illustre  le  processus  d'affaires  «Suivi  de  la  clientèle»: 
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Vincent  ISOZ 


Processus  commercial  33  «Suivi  de  la  clientèle» 


Il  y  a  malheureusement  quelques  difficultés  et  problèmes  courants  avec  les  schémas  (et 
particulièrement  les  processus)  selon  certains  responsables  de  projets: 

1.  Leur  documentation  (très  longue) 

2.  Leur  communication  (nécessite  de  former  régulièrement  les  employés) 

3.  Leur  mise  à  jour  exigée  par  ISO  9001  (nécessite  un  responsable  qualité  à  plein  temps) 

4.  Leur  application12  (nécessite  des  surveillants:  le  responsable  qualité  ou  de  faire 
comprendre  aux  employés  les  possibles  impacts  de  leurs  discours/décisions/gestes 
dans  des  environnements  sensibles) 

5.  La  mesure  de  leur  performance  (exigée  par  ISO  9001) 

6.  Les  audits  internes  pour  vérifier  que  les  processus  soient  bien  suivis 

7.  Les  revues  (réunions)  qui  prennent  du  temps 

8.  La  tendance  naturelle  des  employés  à  trouver  un  moyen  légitime  de  contourner  le 
respect  des  processus. 

Mais  bon  comme  l'aurait  dit  William  Edwards  Deming  (statisticien  qui  est  une  référence 
mondiale  dans  la  gestion  de  projets  contemporaine  et  le  créateur  de  la  démarche  qualité  et  qui 
considère  que  le  seul  langage  de  la  qualité  doit  être  la  statistique  mathématique): 

85%  des  raisons  d'échecs  en  ce  qui  concerne  la  satisfaction  des  clients  est  liée  au  système  et 

aux  processus...  plutôt  qu'à  l'employé. 


12  Un  exemple  assez  "extrême"  est  une  entreprise  qui  avait  des  collaborateurs  qui  ne  savaient  simplement  pas  lire 
(et  le  responsable  AQ  n'était  pas  au  courant). 
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Raison  pour  laquelle  nombreux  sont  ceux  qui  disent  que  sans  objectifs  clairs,  sans  formations 
et  sans  systèmes  de  mesure:  les  résultats  ne  seront  pas  au  rendez-vous  ET  il  ne  sera  pas 
possible  de  lancer  des  améliorations. 

Si  enfin  nous  rappelons  le  vieil  adage  qui  dit  que  l'on  ne  peut  améliorer  que  ce  qui  est 
mesurable  il  n'est  pas  étonnant  que  le  point  fort  de  l'approche  par  processus  est  justement  sa 
capacité  à  mesurer  les  performances. 


Quatre  raisons  de  mesurer  : 

1 .  pour  valider  2.  pour  piloter 

-  les  décisions  antérieures 

-  ...basée  sur  la 

stratégie  et  la  vision  -  ...  basée  sur  les  métriques  convenues 


les  activités  afin 
d'atteindre  les  cibles  définies 


4.  pour  intervenir 

-  identifier  un  point  d’intervention 

-  ...  incluant  les  changements 
subséquents  et  les 
actions  correctives 


3.  pour  justifier 

-  qu'une  action  est  nécessaire 

-  ...  basée  sur  une  évidence 
ou  une  preuve  factuelle  de 
performances  informatiques 


Certains  cependant  argumentent  qu'il  n'est  plus  possible  au  21eme  siècle  de  continuer  à  exercer 
une  approche  analytique  des  organismes  et  qu'il  faut  prendre  de  la  hauteur  et  préférer  une 
approche  plus  globale  centrée  sur  la  stratégie  des  résultats  plutôt  que  sur  le  respect  de  règles 
écrites  qui  se  démodent  aussi  vite  qu'elles  sont  formalisées.  Il  s'agit  d'une  critique  à  laquelle 
j'ai  toujours  une  réponse  très  simple:  il  suffit  d'étudier  un  tout  petit  peu  l'histoire  des  sciences 
dures  et  exactes  depuis  Bacon  pour  voir  avec  quelle  vitesse  tout  notre  environnement  a  été 
bouleversé  depuis  la  mise  en  place  de  méthodes  scientifiques  rigoureuses  et  formalisées  et...  si 
les  entreprises  veulent  repartir  dans  le  moyen-âge  c'est  leur  problème...  De  plus  si  les 
processus  se  démodent  aussi  vite  qu'ils  sont  formalisées  c'est  simplement  que  la  personne  les 
ayant  formalisés  n'est  pas  compétente! 
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“Anyone  w ho  has  never 
made  a  mistalce  has  never 
tried  anythingnew.” 

-  Albert  Einstein  (1077-1755) 


Cette  petite  citation  est  pertinente...  mais  encore  faut-il  se  rappeler  de  ce  qui  est  "nouveau"  en 
entreprise  (car  la  très  grande  majorité  des  employés  utilisent  des  méthodes  et  outils  de  travail 
qui  sont  centenaires). 

7.1.2  Types  de  représentatives 

Tous  les  exemples  de  représentatives  que  nous  allons  donner  ici  ne  sont  pas  faites 
nécessairement  avec  Microsoft  Office  Visio  mais  il  est  cependant  possible  des  toutes  les  créer 
avec  ce  dernier  logiciel. 

Rappelons  qu'au  même  titre  que  "une  image  vaut  autant  que  mille  mots”,  un  "bon  croquis  vaut 
mieux  qu'un  long  discours"  ;-) 

7. 1.2.1  Mind  Mapping 

Le  Mind  Mapping  (appelé  aussi  parfois  "Diagramme  d'affinité")  permet  de  rapidement 
synthétiser  des  idées  ou  concepts  discutés  lors  d'une  réunion.  Le  meilleur  logiciel  pour  faire 
ce  type  de  cartes  à  ce  jour  est  très  probablement  MindManager.  Si  l'on  souhaite  pouvoir 
communiquer  des  MindMap  à  tout  un  département  dans  lequel  vous  êtes  le  seul  à  posséder  un 
logiciel  de  Mind  Mapping  nous  conseillons  alors  plutôt  le  logiciel  FreeMind  qui  permet  de 
transformer  toute  carte  en  une  page  web  interactive  très  pertinente. 
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Develop  key  set  üf 
custo  m  e  r  se  rvi  ce 
practices 


Asseas  Customer  Service  Training  Heeds 

* 

ReviewS  Trial  new  CS  R 
E  ngag  eme  nrt  S  ess  i  o  ns  ^ 


Sequance  &  enable 
pradical  apprcach 
to  meet  companywide 
customer  ta rgets 


State  dear  goals  for  new 
MC  ustc  m  e  r  S  ervice  R  e  pi' 


Increases  "Repeat 
CustomersV 


Préparé  corn  nany  for 
cha  n  ges  in  -  up  p  oiü  ng 
custo  m  er  servi  ce  train  ing^ 

Es+solish  connection 
*  ^  ^etiveen  the  training 
exercises  and  actual 
custo  m  e  r  e  ng  ag  eme  nts 

Develcped  ski  lied 
ir>house  train  ers 
frorri  Customer 
Service  Group 


Ce  type  de  diagramme  (enfin  les  logiciels  associés  disons  plutôt. . .)  peuvent  aussi  très  bien 
être  utilisés  pour  faire  des  "diagrammes  bête  à  cornes"  ou  "diagramme  pieuvre"  (voir  sur 
Internet  car  c'est  trivial). 

7. 1.2.2  Diagramme  d'Ishikawa 

Le  diagramme  d'Ishikawa  (Diagramme  de  causes  et  effet)  ou  diagramme  en  arêtes  de  poisson 
est  le  fruit  des  travaux  de  Kaoru  Ishikawa  pour  la  gestion  de  la  qualité  (en  toute  rigueur:  en 
"contrôle  qualité"). 

Cet  outil  graphique  issu  d'un  brainstorming,  recense  les  causes  aboutissant  à  un  effet.  Son 
analyse  permet  une  aide  à  la  décision  synoptique  pour  soit  corriger  un  fait  existant,  soit  la 
mise  en  place  d'un  projet. 

Les  causes  sont  réparties  traditionnellement  dans  cinq  catégories  appelées  5M: 

1.  Matière:  Les  matières  premières,  et  plus  généralement  les  inputs  du  processus. 

2.  Matériel:  Concerne  l'équipement,  les  machines,  le  matériel  informatique. . . 

3.  Méthode:  Le  mode  opératoire  et  la  recherche  et  développement. 

4.  Main  d'œuvre:  Tout  ce  qui  concerne  les  ressources  humaines. 

5.  Milieu:  L'environnement,  le  positionnement,  le  contexte. 
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Chaque  branche  reçoit  d'autres  causes  ou  catégories  hiérarchisées  selon  leur  niveau 
d'importance  ou  de  détail.  Le  classement  doit  aussi  mettre  en  évidence  les  causes  les  plus 
directes.  Ce  sont  celles  les  plus  proches  de  l'arête  de  poisson. 


MACHINE 


MAN 


InucuripetenC 
T  ëeh'Engr 


LüCk  Df 
"Tr-mninq 


Là&k  «Jl 
Mrûlvùliün 


Pf-dblem 


Migh 

Electric  al 

Overatress 

Occurrences 


Poor 
Qocumen- 
caliün 


Deiectivî 
P  ÜWÉf 

Süpjplit-â 


METHO05 


MATERIALS 


Lac  K cf 

Appropriât? 

Tools 


La  méthode  5M  est  souvent  articulée  autour  des  "bonnes  méthodes  de  fabrication"  (abrégée 
BPF)  qui  s'articulent  autour  de  10  points  et  dont  les  5M  sont  un  résumé: 

S 

1.  Ecrire  les  modes  opératoires  et  les  instructions  afin  de  fournir  une  "feuille  de  route" 
nécessaire  à  la  conformité  aux  bonnes  pratiques  et  à  un  travail  de  qualité  régulier. 

2.  Suivre  scrupuleusement  procédures  et  instructions  pour  prévenir  toute  erreur. 

3.  Renseigner  rapidement  et  précisément  le  travail  en  cours  dans  un  but  de  conformité 
aux  procédures  et  de  traçabilité. 

4.  Prouver  que  nos  systèmes  font  ce  pour  quoi  ils  sont  conçus  en  effectuant  des 
démarches  formelles  de  validation. 

5.  Intégrer  la  productivité,  la  qualité  service  et  du  personnel  dans  la  conception  de 
l'environnement  de  travail. 

6.  Effectuer  la  maintenant  des  outils  de  manière  régulière  et  efficace. 

7.  Développer  et  démontrer  clairement  les  compétences  au  poste  de  travail. 

8.  Protéger  les  produits  contre  tout  défaut  en  adoptant  des  habitudes  régulières  et 
systématiques  d'organisation  et  de  suivi. 

9.  Construire  la  qualité  dans  les  produits  par  un  contrôle  des  processus. . . 
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Planifier  et  Effectuer  régulièrement  des  audits  afin  d'assurer  conformité  au  système  qualité. 

La  variante  la  plus  intéressante  du  diagramme  5M  est  le  diagramme  6M  qui  ajoute  aux  5 
domaines  précédents  celui  de  la  Mesure:  les  causes  correspondant  à  des  biais  ou  erreurs  liés 
aux  indicateurs  utilisés  pour  chiffrer  le  phénomène  à  analyser. 

Les  entreprises  de  services  utilisent  une  version  étendue:  c'est  le  diagramme  7M  qui  rajoute 
les  catégories  Management  (que  l'on  pourrait  considérer  comme  redondante  avec  la  catégorie 
main-d'œuvre)  et  Moyens  financiers. 

Pour  terminer  signalons  aussi  les  classiques  8P  (Price,  Promotion,  People,  Processes,  Place, 
Policies,  Procedures  et  Product)  et  les  4S  (Surroundings  (environnement),  Suppliers,  Systems, 
Skills)  ou  le  6M+E  (man,  machine,  material,  method,  management,  measurement  et 
environment). 

7. 1.2.3  Organigrammes  (O.B.S./W.B.S./P.B.S./R.B.S.) 

Le  responsable  de  projets  pour  gérer  l'information  au  mieux  et  dans  les  règles  de  l'art  est 
confronté  à  la  nécessite  de  créer  plusieurs  organigrammes  qui  pour  certains  sont  exigés  pour 
le  bon  fonctionnement  de  logiciels  spécialisés  en  gestion  de  projets  de  quelques  éditeurs. 

Nous  avons  ainsi  dans  l'odre  des  plus  utilisés  au  moins  utilisés  dans  la  pratique 

•  W.B.S.  Work  Breakdown  Structure:  Permettant  de  construire  un  organigramme 
structurel  des  tâches  avec  un  numéro  d'identifiant  (d'attribution)  unique  hiérarchisé  et 
non  modifiable  à  travers  tous  les  projets  d'entreprises.  Ce  numéro  permet  de  faciliter 
la  communication  et  également  de  mieux  tracer  (suivre)  les  modifications 
structurelles  effectuées  sur  le  projet  pendant  l'exécution  de  ce  dernier. 

Il  s'agit  du  seul  organigramme  de  projet  qui  à  ma  connaissance  est  normalisée  par 
l'AFNOR  sour  dénomination  S.F.T.  pour  Structure  de  Fractionnement  de  Travail. 

•  A.B.S.  Activity  Breakdwown  Structure:  Selon  le  PMI,  le  responsable  de  projet  ne 
devrait  s'occuper  au  niveau  du  planning  que  de  la  A.B.S.  qui  représente 
l'organigramme  des  programmes  du  projet,  des  phases  et  des  livrables  et  en  aucun  cas 
aller  jusqu'au  détail  des  tâches.  Toujours  selon  le  PMI,  le  détail  des  tâches  pour  que 
la  A.B.S.  devienne  une  W.B.S.  est  la  responsabilité  des  responsables  d'équipes. 

•  R.B.S.  Ressource  Breakdown  Structure:  Il  s'agit  de  l'organigramme  des 
compétences/métiers  des  ressources  du  projet.  L'idée  étant  de  pouvoir  rapidement 
trouver  qui  a  des  compétences  dans  le  projet  qui  sont  dans  le  même  le  même  domaine 
de  spécialisation  pour  des  éventuels  remplacements  ou  pour  compléter  des  équipes  en 
cas  d'urgences  (retards  à  atteneur).  La  R.B.S.  des  ressources  est  parfois  aussi 
confondue  avec  la  Risk  Breakdown  Structure  qui  est  l'organigramme  structurel  des 
risques  (mais  je  n'ai  jamais  vu  ce  dernier  être  utilisé  dans  la  pratique)  ou 
l'organigramme  des  projets  par  niveau  de  risque  tel  que  proposé  depuis  2004  par  le 
P.M.I. 

•  O.B.S.  Organizational  Breakdown  Structure:  Il  s'agit  du  plus  souvent  de 
l'organigramme  hiérarchique  des  ressources  du  projet  et  donc  indirectements  de  la 
structure  hiérarchique  des  départements  ou  groupes  de  travail  intervenant  sur  le 
projet.  L'O.B.S.  permet  de  ne  pas  aller  à  la  pêche  à  l'information  quand  un  décideur 
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est  absent  (afin  de  rapidement  savoir  qui  est  le  n+1  qui  doit  alors  se  substituer  à  la 
personne  absente)  et  également  de  formaliser  les  responsabilités  de  tout  à  chacun  et 
ce  par  projet  et  enfin  (et  surtout!)  de  générer  de  statistiques  une  fois  le  projet  terminé 
par  groupe  de  travail  ou  département. 

•  P.B.S.  Product  Breakdown  Structure:  Il  s'agit  de  l’organigramme  structurel 
représentant  l'ordre  d'assemblage  d'un  produit.  Dans  la  nomenclature  la  P.B.S.  est 
plus  souvent  connue  sous  la  dénomination  de  "nomenclature  produit"  et  permet  donc 
pour  chaque  tâche  du  projet  d'identifier  à  quelle  partie  structuelle  du  produit  final  la 
tâche  appartient. 

•  C.B.S.:  Communication  Breakdown  Structure:  Permettant  de  définir  le  flux  de 
communication  au  sein  du  projet.  Ainsi,  un  client  n'a  pas  à  s'adresser  directement  aux 
exécutants  du  projet  mais  doit  passer  par  un  filtre  de  personne  qui  vont  s'occuper  de 
distribuer  l'information  aux  bonnes  personnes,  au  bon  moment  en  gérant  les  priorités 
(ne  pas  respecter  ce  type  de  flux  amène  quasiment  systématiquement  à  une  gestion 
catastrophique  des  priorités). 

Voici  un  exemple  de  W.B.S.  simplifié: 


Figure  6  Exemple  de  W.B.S. 

Le  terme  W.B.S.  a  une  définition  formelle  dans  la  norme  d'origine  US  MIL-HDBK-881A 
(gratuitement  disponible  sur  Internet  et  comportant  128  pages).  Il  est  recommandé  de 
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consulter  la  norme  pour  bien  différencier  rigoureusement  la  notion  d'A.B.S.  de  celle  de 
W.B.S.. 

Indiquons  que  le  PMI  recommande  que  tout  responsable  de  projet  doit  refuser  de  reprendre  ou 
d'exécuter  un  projet  s'il  n'y  a  pas  de  W.B.S.  de  disponible  (ou  de  W.B.S.  sous  forme  de 
planning  de  Gantt  que  nous  allons  voir  de  suite  après)  mais  en  même  temps...  ils 
recommandant  de  ne  pas  obliger  à  travailler  avec....  Le  PMI  n'étant  pas  à  une  contradiction 
près... 

7. 1.2.4  Gantt 

Le  diagramme  de  Gantt  est  un  outil  utilisé  (souvent  en  complément  d'un  réseau  PERT)  en 
ordonnancement  et  gestion  de  projet  et  permettant  de  visualiser  dans  le  temps  les  diverses 
tâches  liées  composant  un  projet  (il  s'agit  d'une  représentation  d'un  graphe  connexe,  valué  et 
orienté).  Il  permet  de  représenter  graphiquement  l'avancement  du  projet  sous  la  forme  d'un 
graphe  connexe  (toute  tâche  doit  avoir  une  liaison  entrante  et  sortante  excepté  le  jalon  de 
début  du  projet  et  celui  de  fin  du  projet),  valué  (chaque  tâche  à  une  durée  non  nulle  ou  nulle) 
et  orienté  (bon  ça  c'est  simplement  à  cause  de  la  flèche  du  temps). 

Cet  outil  répond  à  deux  objectifs:  planifier  de  façon  optimale  et  communiquer  sur  le  planning 
établi  et  les  choix  qu'il  impose 
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L'exemple  de  diagramme  de  Gantt  ci-dessus  est  très  bon  car  comme  vous  pouvez  le  constater 
les  liaisons  entre  les  tâches  ne  sont  pas  visibles.  Il  s'agit  donc  en  toute  rigueur  d'un  planning  et 
non  d'un  Gantt  (car  rien  n'est  connexe)  et  cela  signifie  aussi  par  extension  que  les  dates  ne  se 
mettront  pas  à  jour  en  cascade  automatiquement  lors  d'une  modification  du  plan  de  projet  et 
que  le  calcul  des  marges  totales  et  libres  seront  erronnées. 
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7. 1.2.5  PERT 


Le  graphique  PERT  est  une  technique  de  gestion  de  projet  qui  permet  de  visualiser  la 
dépendance  des  tâches  (réseau  logique)  et  de  procéder  à  leur  ordonnancement  en  dehors  du 
ligne  de  temps  et  par  un  algorithme  précis  (que  les  responsables  de  projets  appliquaient  à  la 
main  jusqu'aux  années  1980. . .)  de  déterminer  le  chemin  critique  du  projet  ainsi  que  les 
marges  totales  et  libres. 


De  nos  jours,  très  rares  sont  les  gens  utilisant  encore  le  PERT  (appelé  aussi  "réseau  de 
tâches").  Les  logiciels  permettant  de  calculer  les  marges  ainsi  que  le  chemin  critique 
directements  sur  le  Gantt  cette  représentative  est  abandonée  petit  à  petit  par  les  praticiens. 

7. 1.2.6  Time-Line 

Une  frise  chronologique  ou  ligne  du  temps  est  une  représentation  linéaire  qui  associe  des 
événements  à  leurs  positions  dans  le  temps  le  long  d'une  échelle  graduée,  ce  en  quoi  elle  se 
rapproche  d'une  chronologie. 

Dans  les  entreprises,  elle  permet  facilement  lors  de  réunions  de  communiquer  à  un  publique 
de  non  spécialistes  (qui  n'arrivent  pas  à  lire  le  Gantt)  les  jalons  d'un  projet. 
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(L 
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Pré-étude  acceptée 


mai-00 


24.04.2009 


26.05.2009 


7. 1.2.7  Planification  linéaire 

Chaque  pays  utilise  des  appellations  différentes  pour  ce  type  de  planning  qui  est  pour  ce  que 
nous  savons  ni  normalisé,  ni  un  standard  dans  le  domaine  de  la  gestion  projets: 

•  Planning  chemin  de  fer 

•  Planification  linéaire 

•  Diagramme  Espace-Temps  ou  Temps-Distance 

•  Linear  Scheduling  Method  (LSM) 

•  Time  Distance  Diagram 

•  Time  Location  Diagram 

•  Time  Chainage 

•  French  Diagram 

•  March  Chart 

Les  plannings  chemin  de  fer  transmettent  plus  d’informations  que  les  plannings  traditionnels 
en  raison  de  la  conjugaison  entre  les  données  temporelles  et  géographiques.  La 
compréhension  du  plan  de  construction  en  est  simplifiée,  plus  rapide  et  plus  profonde. 

•  L’axe  distance  est  souvent  représenté  à  l’horizontale  et  le  temps  à  la  verticale  (même 
si  cela  peut  être  inversé).  Ainsi,  la  pente  de  chaque  de  tâche  indique  la  vitesse  ou  le 
taux  de  productivité  de  l’équipe  qui  l’exécute  sur  le  terrain. 

•  La  superposition  de  certaines  tâches  peut  supposer  des  incohérences  planning  ou  des 
défauts  de  conception. 

•  Les  tâches  non-linéaires  sont  représentées  par  des  rectangles  (exemples  :  ouvrages 
d’art,  ouvrages  hydrauliques,  etc.) 

•  Les  zones  restreintes  ne  permettent  pas  la  planification  des  tâches,  sur  une  plage 
temps-distance  donnée.  Cela  peut  être  pour  des  blocages  fonciers  ou 
environnementaux  par  exemple. 
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Ou  plus  élégamment: 


Les  logiciels  qui  font  cela  sont: 
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•  http://www.logikalproiects.com 

•  https://www.tilos.org/ 

7. 1.2.8  Diagramme  de  flux 

En  gestion  et  plus  précisément  selon  le  standard  ISO  9001  pour  la  gestion  de  la  qualité,  un 
diagramme  de  flux  est  un  système  organisé  d'activités  mesurables  déclenché  par  un  élément 
prévu  ou  imprévu  qui  utilise  des  ressources  (personnel,  équipement,  matériels  et  machines, 
matière  première  et  informations)  pour  transformer  des  éléments  entrants  en  éléments  de 
sortie  dont  le  résultat  final  attendu  est  un  produit. 

Voici  quelques  définitions  officielles: 

•  Selon  la  norme  AFNOR  X  50  176:  un  processus  est  un  système  d'activité  qui  utilise 
des  ressources  pour  transformer  des  éléments  entrants  en  éléments  sortants. 

•  Selon  la  série  de  normes  ISO  9000:  un  processus  est  un  ensemble  d'activités  corrélées 
ou  interactives  qui  transforment  des  éléments  d'entrée  éléments  de  sortie. 

Lors  de  la  construction  d'un  diagramme  de  flux  (processus)  le  responsable  de  projet  peut 
identifier  des  étapes  inutiles  ou  manquantes  dans  un  processus  de  travail  et  analyser  la 
conformité,  la  performance  de  celui-ci  dans  le  temps  afin  de  déterminer  son  efficacité  en 
utilisant  la  méthodologie  Six  Sigma  (ISO  13053-1:2011).  En  utilisant  la  méthodologie  Kaizen 
il  est  aussi  souvent  possible  d'optimiser  le  temps  d'exécution  d'un  processus  et  sa  fiabilité.  Il 
est  aussi  possible  d'utiliser  la  méthodologie  Six  Sigma  pour  s'assurer  de  la  stabilité  statistique 
d'un  processus  ou  d'utiliser  l'AMDEC  pour  le  calcul  de  sa  fiabilité. 

Un  processus  est  donc  un  outil  très  utile  pour  s'assurer  de  la  stabilité,  la  conformité  (qualité)  et 
le  respect  des  règles  de  travail  dans  tout  domaine  d'activité  quel  qu'il  soit  et  ceci  avec  tout  le 
retour  d'expérience  nécessaire  afin  d'éviter  des  erreurs  déjà  vécues. 

Pour  qu'un  processus  culture  dans  une  organisation  nous  considérons  souvent  les  chiffres 
suivants: 

•  6  à  18  mois  de  définition 

•  2.5  ans  de  mise  en  vie,  d'instrumentation 

•  1  à  2  ans  d'optimisation  des  activités  et  organisations 

Les  spécialistes  en  processus  recommandent  d'éviter  la  construction  de  flux  à  rétroaction  afin 
de  garder  le  schéma  le  plus  clair  possible  et  de  s'arranger  afin  que  le  processus  et  sa 
documentation  tiennent  tous  deux  sur  une  seule  et  unique  page  A4. 

Nous  considérons  également  deux  rôles  majeurs  dans  le  cas  des  processus: 

1.  Le  Gestionnaire  de  processus:  Les  responsabilités  du  gestionnaire  de  processus 
comprennent  la  planification  et  la  coordination  de  toutes  les  activités  nécessaires  à  son 
fonctionnement,  sa  surveillance  et  l'établissement  de  tableaux  de  bords  sur  le 
fonctionnement  du  processus.  Le  rôle  du  gestionnaire  de  processus  est  souvent 
confondu  avec  celui  de  propriétaire  du  processus  ( voir  Propriétaire  de  processus), 
mais  ces  deux  rôles  peuvent  être  distincts  dans  les  grandes  organisations. 
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2.  Le  Propriétaire  de  processus:  Les  responsabilités  du  propriétaire  de  processus 

comprennent  la  recherche  de  sponsors,  la  conception,  la  documentation,  la  gestion  des 
changements,  l'amélioration  continue,  le  contrôle  du  respect,  la  formation  du  processus 
et  de  ses  mesures.  Ce  rôle  est  souvent  confondu  avec  celui  de  gestionnaire  du 
processus  ( voir  Gestionnaire  de  processus),  mais  ces  deux  rôles  peuvent  être  distincts 
dans  les  grandes  organisations. 

Les  formes  à  utiliser  seront  conformes  à  ISO  5807:1985. 


Remarque:  Un  diagramme  de  flux  comportant  des  bandes  fonctionnelles  est  conformément  au 
BABOK  devrait  être  appelé  un  "diagramme  d'activité"  et  non  un  "diagramme  de  flux". 

Il  est  possible  dans  MS  Visio  (par  exemple...)  d'ajouter  des  phases  aux  diagrammes  de  flux 
fonctionnels  comme  celui  ci-dessus.  Dès  lors,  nous  parlons  de  modèle  MOSI  pour  "Méthode 
d'Organisation  et  Stratégie  d'intervention". 

Les  informations  (métadonnées)  qu'il  est  typique  de  relier  à  chaque  étape  sont: 

-  Créé  par/Créé  le  (ISO) 

-  Identifiant  étape  processus  (ISO) 

-  Responsable  (ISO)/Back-Up 

-  Intervenants  (ISO) 

-  Degré  de  délégation 

-  Niveau  de  confidentialité 

-  Coût  médian  d'exécution/Déviation  de  coût  (Six  Sigma) 

-  Temps  moyen  d'exécution  /Déviation  de  temps  (Six  Sigma) 

-  Gravité  défaillance  (AMDEC) 

-  Effet  potentiel  de  défaillance  (AMDEC) 

-  Cause  potentielle  de  défaillance  (AMDEC) 

-  Délai  moyen  entre  deux  non  conformités/MTBF  (AMDEC) 
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Quantifiable?  (Six  Sigma) 

Niveau  de  qualité  en  %  (Six  Sigma) 
Contact  client 


Enfin  signalons  au  niveau  global  du  processus  les  indicateurs  suivants: 

-  Niveau  de  maturité  CMM 

-  Rendement  Global  Combiné  (voir  page  130) 

-  Ratio  d'efficacité  du  processus  (rapport  entre  temps  effectif  de  travail  et  temps  total) 
Ce  dernier  indicateur  étant  très  simple  donnons  de  suite  sa  définition: 


temps  de  travail  effectif 


temps  total  y  compris  les  temps  d'attente 


Comme  on  me  le  demande  souvent  voici  la  signification  des  formes  standards  de  processus 
(je  fournirai  un  gabarit  Microsoft  Office  Visio  avec  légendes  et  conformités  à  ISO  5807 
pendant  la  formation): 

Terminaison:  Utilisez  cette  forme  pour  la  première  et  dernière  étape  d'un  processus. 


Processus:  Cette  forme  représente  une  étape  dans  votre  processus. 


Processus  prédéfini:  Utilisez  cette  forme  pour  un  ensemble  de  sous-étapes  d'un  sous- 
processus  se  trouvant  défini  ailleurs,  souvent  sur  une  autre  page  du  même  fichier. 


Décision:  Cette  forme  indique  une  étape  où  la  décision  sortante  dicte  la  prochaine  étape  à 


faire.  Il  peut  y  avoir  plusieurs  sorties,  mais  souvent  les  deux  les  plus  courantes  sont  Oui  et 

Non. 


Document:  Cette  forme  représente  une  étape  qui  résulte  en  la  création  d'un  document. 
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Données:  Cette  forme  indique  que  l'information  arrive  dans  le  processus  depuis  l'extérieur  ou 
quitte  le  processus.  Cette  forme  peut  aussi  être  utilisée  pour  représenter  du  matériel  et  est 
parfois  appelée  "forme  d'entrée/sortie". 


Données  stockées:  Cette  forme  est  utilisée  pour  représenter  de  l'information  qui  sera  stockée. 


Référence  sur  page:  Cette  forme  indique  simplement  que  la  suite  d'un  processus  se  trouve 
sur  une  autre  page.  Ceci  est  particulièrement  utile  pour  les  grands  processus  prenant  plusieurs 
pages. 


O 

Référence  hors  page:  Forme  utilisée  pour  créer  un  lien  dynamique  (interactif)  permettant  de 
renvoyer  automatiquement  sur  une  autre  page  pour  la  suite  d'un  processus  ou  l'envoi  à  un 
sous-processus. 


Entrée  manuelle:  Étape  utilisée  pour  représenter  le  fait  qu'une  personne  apporte  une 
information  au  processus. 


Opération  manuelle:  Étape  utilisée  pour  représenter  le  fait  qu'une  étape  est  effectuée  par  un 
être  humain. 
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Stockage  interne:  Cette  forme  représente  une  information  saisie  sur  un  ordinateur. 


Donnée  directe:  Cette  forme  représente  une  information  stockée  comme  un  unique 
enregistrement  dans  une  base  de  données  typiquement.  Cette  forme  représente  comme  un 
disque  dur  stock  des  données. 


Donnée  séquentielle:  Quand  une  information  est  stockée  de  manière  séquentielle,  elle  ne  peut 
être  récupérée  par  hypothèse  que  manière  séquentielle  aussi.  Par  exemple,  pour  accéder  à 
l'enregistrement  numéro  7,  vous  devrez  d'abord  passer  par  les  enregistrements  1  à  6. 


Enregistreur  carte  ou  papier:  Les  anciens  ordinateurs  utilisaient  des  systèmes  de  cartes  et 
papier  pour  stocker  et  rapatrier  des  données  et  stocker  pour  exécuter  des  programmes. 


Affichage:  Cette  forme  représente  une  information  qui  sera  affichée  par  une  personne, 
typiquement  sur  un  écran  d'ordinateur. 


Préparation:  Cette  forme  indique  où  les  variables  d'un  système  mécanique  ou  informatique 
doivent  être  réinitialisées  pour  une  procédure. 


Mode  parallèle:  Cette  forme  est  utilisée  pour  indiquer  où  deux  processus/actions/étapes 
différents  peuvent  s'exécuter  simultanément  (en  parallèle). 
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Limite  de  boucle:  Cette  forme  représente  le  nombre  de  fois  qu'une  boucle  d'un  processus  doit 
s'exécuter  avant  de  continuer  à  la  prochaine  étape. 


\ 


Contrôle  de  transfert:  Cette  forme  indique  la  manière  particulière  dont  une  transition  entre 
deux  étapes  doit  se  faire  en  indiquant  avec  une  initiale  le  type  de  transition  au  milieu  de  la 
forme  (par  exemple:  P  flux  de  type  permanent,  T  flux  temporaire,  etc.) 


7. 1.2.8. 1  Fiche  processus 

Il  y  a  deux  "écoles"  en  ce  qui  concerne  les  fiches  processus: 

1.  Ceux  qui  font  la  fiche  processus  sur  la  même  page  et  le  même  côté  du  processus  mais 
à  droite  (ce  qui  réduit  malheureusement  considérablement  la  place  pour  la 
schématisation  du  processus  mais  qui  a  pour  avantage  que  tout  tient  sur  une  seule  page 
A4).  C'est  une  technique  obsolète  pour  ceux  qui  travaillent  sans  papier  en  ce  début  de 


eme 


21 


siècle. 


2.  Ceux  qui  font  une  fiche  processus  sur  un  page  à  part  (ce  qui  malheureusement 
nécessite  de  retourner  la  page/feuille  mais  a  pour  avantage  de  pouvoir  mettre  plus 
d'information  que  la  première  méthode). 

Personnellement,  je  préconise  dans  la  majorité  des  cas  la  deuxième  et  voici  un  exemple  type 
de  fiche  processus: 
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K  fl  Le  (description  résumée  de  l'activité): 

Actions  à  mener  pour  mettre  en  place  et  suivre  la  mise  en  place  dHun  système  qualité  dans  un  domaine  particulier  d’activité  de  l’entreprise. 


O hjectiflf s}/ Exige nce(s)/ Finalité! s)  du  processus: 

Pour  l’entreprise:  Assurer  un  niveau  de  qualité  quantifiable  pour  les  clients,  obtenir  des  homologations  ou  certifications  exigées  par  les 
clients,  augmenter  la  bien-être  des  employés  et  réduire  le  turnover. 

Pour  le  client:  Démontrer  le  démarche  et  la  volonté  de  faire  de  la  qualité,  assurer  le  respect  de  normes,  réglementations  pour  les  services 
fournis  ou  les  produits  vendus. 


Valeur  ajoutée: 

Montrer  que  nous  nous  soucions  de  la  qualité  de  nos  produits  et  services,  de  la  satisfaction  de  nos  clients  et  du  bien-être  de  nos  employés. 


Fa it(s)  généra teur(s|  du  processus/ Fréquence: 

Au  moins  tous  les  3  ans.  Sinon  une  fois  par  semestre 


IntrantfsJ: 

Référence  de  normes/réglementations;  Cahier  des  charges  de  la  direction  (  approuvé  et  signé) 
Extrant(s): 

Dossier  Qualité;  Procès  Verbaux:  Rapports  d'audit;  Sondages  de  satisfaction; Échéanciers 


Description  des  actiuns/epérations  identifiées: 

-  Aucune  description  détaillée  nécessaire  à  cc  jour  (le  texte  dans  le  schéma  est  jugé  suffisant  par  les  utilisateurs  à  ce  jour) 


Équipements  {machines,  véhicules,  Indiciels  etc,): 

Logiciel  SMQ  avec  G  KD  (Gestion  Électronique  Documentation)  intégrant  une  gestion  des  versions,  un  moteur  de  flux  automatisés 
d'approbation  ainsi  que  des  tableaux  de  bord  de  mesure  de  la  performance  de  la  qualité  i gestion  des  processus  et  anomalies  qualité  ainsi 
que  des  tâches  internes. 

Intervenants: 

Responsable  AQ  (ingénieur  qualité);  Direction  (compétences  managériales);  Auditeur  externe  (certifié);  Représentant  du  personnel 
(nommé  pat  le  personnel) _ 

Indicateurs: 

-  Points  EKQM 

-  M  T  B  K  (Mean  Time  Between  Fa  dure) 

-  RTY  (Rolled  Troughput  Yield) 

-  Niveau  CM M 

-  Rapport  Anomalies/Processus  exécutés 

-  Nombre  d'exécutions  de  ce  processus 


Remarques  (précautions  Légales,  erreurs  types*  ctc+)t 
-  Rien  à  signaler 


ÀDDCXe(S)t 

Manuel  Qualité  ISO  9001  (ici):2Ü08;DossiereduQua  (ici );É valuation  EFQM  (ici);Dossîet  évaluation  lîFQM  (ici) 


Figure  7  Exemple  fiche  processus 
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7.1. 2.8.2  Diagramme  de  flux  SIPOC 

SIPOC  est  l'acronyme  de  Supplier  Input  Process  Output  Customer,  en  français:  Fournisseurs 
Entrées  Processus  Sorties  Clients. 

Un  diagramme  SIPOC  est  un  outil  de  visualisation  pour  identifier  tous  les  éléments  pertinents 
associés  à  un  processus  P  :  son  périmètre  (frontières,  début  et  fin),  les  sorties  (O)  les  entrées 
(I),  les  fournisseurs  (S)  et  les  clients  (C).  Il  est  recommandé  d'employer  le  SIPOC  dans  la 
phase  initiale  d'un  projet  d'amélioration  d'un  processus.  Il  fournit  plus  d'information  qu'une 
cartographique  qui  se  concentre  sur  la  description  sommaire  des  étapes.  Il  oblige  à  définir  qui 
sont  les  fournisseurs  et  les  clients. 

Dans  la  méthodologie  Six  Sigma,  le  SIPOC  est  utilisé  pendant  la  première  étape  du  DMAIC, 
Définir,  afin  de  décrire  le  processus  métier  dont  on  veut  améliorer  la  qualité.  Comme  ce 
diagramme  est  propre  à  Six  Sigma,  il  n'est  pas  soumis  à  la  schématique  ISO  5807. 

Voici  par  exemple  un  exemple  de  diagramme  SIPOC  de  Flux  prépresse  dans  le  cas  d'un 
workflow  PDF/X  (vous  pouvez  demander  le  PDF  de  qualité  original  à  votre  formateur  si 
besoin): 
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7. 1.2.9  Analyse  par  arbres  d'erreurs  (A.A.E.) 

L'analyse  par  arbres  d'erreurs,  appelée  aussi  "analyse  par  arbres  de  défaillances  probabilistes" 
(A.A.D.P.)  ou  encore  "analyse  par  arbres  de  pannes"  A.A.P.)  sont  utilisés  dans  les  études 
qualitatives  ou  quantitatives  de  fiabilité  des  systèmes  et  font  partie  intégrante  de  la  norme 
ISO  31010. 

Basée  sur  une  représentation  graphique  mettant  en  évidence  les  relations  de  cause  à  effet, 
cette  technique  est  complétée  par  un  traitement  mathématique  qui  permet  la  combinaison  de 
défaillances  simples  ainsi  que  leur  probabilité  d'apparition.  Cet  outil  permet  donc  de 
quantifier  l'occurrence  d'un  Événement  Redouté  (E.R.)  de  bien  mettre  en  évidence  les  causes 
profondes  probables  d'un  problème  et  les  interactions  avec  d'autres  causes. 

Un  arbre  de  défaillance  est  généralement  construit  de  haut  en  bas  avec  la  ligne  la  plus  haute 
ne  comportant  que  l'évènement  dont  nous  cherchons  à  décrire  comment  il  peut  se  produire. 
Cependant  il  est  par  la  suite  souvent  lu  de  bas  en  haut. 

Chaque  ligne  détaille  la  ligne  supérieure  en  présentant  la  combinaison  ou  les  combinaisons 
susceptibles  de  produire  l'évènement  de  la  ligne  supérieure  auquel  elles  sont  rattachées. 

Ces  relations  sont  représentées  par  des  liens  logiques  OU,  et  ET  (on  emploie  généralement  le 
terme  de  "porte"  OU  et  de  "porte"  ET)  comme  le  montre  le  schéma  ci-dessou  fait  avec 
MS  Visio: 


L'arbre  ci-dessus  est  donc  un  exemple  d'analyse  par  arbre  de  pannes  qualitatif  puisque  aucune 
probabilité  n'est  indiquée.  Dans  MS  Visio  il  est  très  pénible  d'associer  des  probabilités  car  il 
faut  construire  toutes  les  formules  à  la  main.  Je  conseille  vivement  l'utilisation  du  logiciel 
Isograph  pour  faire  des  A.D.P.  quantitatifs  de  haut  niveau  rapidement  (ce  dernier  logiciel 
présenté  au  début  de  ce  support  associe  la  méthode  de  Monte-Carlo  avec  les  A.D.P.). 

Par  contre  si  des  probabilités  sont  associées,  rappelons  les  axiomes  de  Kolmogorov  suivants: 

0  <  P(A)  <  1 


pour  tout  événement  A  et: 
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P(U)  =  1 


pour  l'univers  de  tous  les  événements.  Nous  avons  aussi  si  deux  événements  A  et  B  sont 
indépendants  la  probabilité  que  les  deux  événements  se  produisent  en  même  temps  (porte 
ET): 


P(A  n  B)  =  P(A)P(B) 

et  si  les  événements  sont  mutuellement  exclusifs,  nous  avons  la  probabilité  disjointe  (porte 
OU  compatible)  que  soit  A  ait  lieu  soit  B  ait  lieu  (mais  sans  prendre  donc  en  compte  que  les 
deux  aient  lieu  en  même  temps)  suivante: 

P(A  u  B)  =  P(A)  +  P(B)  -  P(A  n  B) 

et  si  les  événements  sont  non  mutuellement  exclusifs  (porte  OU  incompatible),  nous  avons  la 
probabilité  conjointe  suivante: 


P(A  uB)  =  P{A)  +  P(B) 

Enfin,  si  les  événements  sont  totalement  incompatibles  (porte  XOR)  nous  avons: 

P{A  ®B)  =  P(A)  +  P(B)  -  2 P(A)P(B) 

Le  lecteur  intéressé  trouver  un  autre  exemple  avec  la  légende/standardisation  des  formes  dans 
la  norme  ISO  31010:2009  ou  CEI  61025  annexe  B. 14  (ou  sur  Wikipedia  US). 

7.1.2.10  Total  Quality  Management  (TQM) 

La  qualité  totale  (Total  Quality  Management,  TQM  en  anglais),  dont  la  traduction  japonaise 
est  le  Kaizen,  est  une  démarche  quasi  psychanalytique  de  gestion  proactive  de  la  qualité  (de 
toute  façon  tout  doit  être  proactif  dans  la  gestion...)  dont  l'objectif  est  l'obtention  d'une  très 
large  mobilisation  et  implication  de  toute  l'entreprise  (total)  pour  parvenir  à  une  gestion 
(management)  par  la  qualité  (quality)  parfaite. . .  en  réduisant  au  maximum  les  gaspillages  et 
en  améliorant  en  permanence  les  éléments  de  sortie  (outputs)  à  très  long  terme.  Selon  le  PMI 
l'idée  est  que  des  améliorations  continues  infinitésimales  sont  préférables  à  des  améliorations 
brutales  de  la  qualité  (curieux  que  les  gestionnaires  de  la  majorité  des  organisations  semblent 
oublier  systématique  cette  règle  depuis  presque  100  ans...). 

Cette  démarche  repose  sur  ISO  9004,  référentiel  qui  sert  de  document  explicatif  au  standard 
ISO  9001. 

Cette  méthodologie  et  sa  représentative  associé  est  étroitement  liée  à  la  TPM  (Total 
Productivity  Management,  TPM  en  anglais)  dont  le  principe  se  résume  grossièrement  aux 
trois  points  suivants: 

•  Maintenance:  maintenir  en  bon  état  (réparer,  nettoyer,  graisser) 

•  Productive:  assurer  la  maintenance  tout  en  produisant 

•  Totale:  considérer  tous  les  aspects  et  y  associer  tout  le  monde  (à  tous  les  rangs!) 
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Donc  au  même  titre  que  la  TQM  (appliqué  à  la  qualité  en  générale  et  pas  seulement  à  la 
production),  la  TPM  consiste  à  chercher  à  maximiser  le  temps  productif,  réduire  le  temps  non 
productif  dû  aux  arrêts  et  pannes,  conserver  les  cadences  optimales  et  réduire  la  non-qualité13. 

Au-delà  du  simple  maintien  en  bon  état  des  machines  ou  de  leur  place  de  travail,  la  démarche 
TQM/TPM  pousse  à  modifier  et  à  améliorer  celles-ci.  L'implication  des  employés  est 
l'occasion  d'élever  leur  niveau  de  compétence  et  d'enrichir  leurs  tâches  en  leur  confiant  la 
maintenance  de  premier  niveau  (avec  leur  accord  et  s'ils  en  sont  motivés!).  Par  ailleurs,  ils 
connaissent  leur  outil  de  travail  et  l'environnement  associé  de  manière  intime.  Sauf  si  les 
employés  sont  temporaires  et/ou  d'un  niveau  trop  faible,  ou  pas  motivés  pour  des  raisons 
quelconques,  ils  ne  se  sentent  pas  concernés  par  ce  qui  se  passe,  ils  subissent,  c'est  un 
problème  de  motivation  et  de  compétence. 

L'indicateur  utilisé,  le  taux  de  rendement  synthétique  (TRS)  qui  est  le  rapport  entre  temps 
utile  et  temps  employé,  mérite  son  qualificatif  car  il  restitue  une  vision  simple  et  sévère,  qui 
englobe  tous  les  paramètres  affectant  le  rendement  de  la  machine  selon  le  triptyque 
disponibilité,  performance  et  qualité.  L'analyse  des  composantes  du  TRS  indique  où  les 
efforts  sont  à  porter. 


P  =  temps  d'ouverture 


R  =  temps  requis 


Arrêts  planifiés 


F  =  temps  de  foiKtlonnement 


Pannes,  pertes 


E  =  temps  net 


Perte 

odeiKe 


U  =  temps 

Non- 

utile 

qualité 

Figure  8  Principe  de  découpage  analyse  TPM 

La  représentative  type  des  schémas  TQM  et  TPM  ressemble  énormément  à  ISO  5807:85. 


13  La  non-qualité  ne  se  limite  pas  à  celle  qui  est  détectée  par  le  client. 
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Définitions: 

Dl.  Manager  par  la  qualité  c'est  appliquer  au  système  (ensemble  de  processus) 
d'organisation  les  principes  qui  permettent  l'amélioration  et  le  développement  harmonieux  et 
durable  du  système. 

D2.  Manager  de  la  Qualité  c'est  appliquer  les  principes  qui  permettent  d'assurer  la  qualité  du 
résultat  d'activités. 

7.1.2.11  Business  Process  Management  Notation 

Business  Process  Modeling  Notation  a  été  développée  par  la  Business  Process  Management 
Initiative  (BPMI),  et  est  maintenant  maintenue  par  l'Object  Management  Group  (OMG) 
depuis  leur  fusion  en  2005.  Le  but  principal  de  BPMN  (www.bpmng.org  pour  la 
documentation  détaillée  et  gratuite)  est  de  fournir  une  notation  qui  soit  réellement 
compréhensible  par  tous  les  utilisateurs  de  l'entreprise,  depuis  les  analystes  métier  qui  créent 
les  ébauches  initiales  des  procédures,  jusqu'aux  développeurs  responsables  de  mettre  en  place 
la  technologie  qui  va  exécuter  ces  procédures,  et  finalement,  jusqu'aux  utilisateurs  de 
l'entreprise  qui  vont  gérer  et  monitorer  ces  procédures.  Ainsi,  BPMN  crée  un  pont  standardisé 
pour  combler  le  vide  entre  la  modélisation  des  procédures  d'entreprise  et  la  mise  en  place  des 
procédures. 
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Le  meilleur  logiciel  que  je  connaisse  à  ce  jour  pour  faire  de  la  BPMN  de  manière 
professionnelle  et  rapide  est  BizAgi  (http://www.bizagi.com) 

7.1.2.12  IDEFO 

La  SADT  (en  anglais  Structured  Analysis  and  Design  Technique)  -  connue  aussi  sous  le  label 
I.DEF.O  (en  anglais  Intégration  Définition  for  Function  modeling)  -  est  l'un  des  standards  de 
description  graphique  d'un  système  complexe  par  analyse  fonctionnelle  descendante,  c'est-à- 
dire  que  l'analyse  chemine  du  général  (dit  "niveau  A-0")  vers  le  particulier  et  le  détaillé  (dits 
"niveaux  Ap").  SADT  est  une  démarche  systémique  de  modélisation  d'un  système  complexe 
ou  d'un  processus  opératoire. 

Voici  le  principe  du  concept: 
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et  voilà  ce  que  fait  par  exemple  en  réalité  un  logiciel  comme  Microsoft  Office  Visio: 


Intégration  Définition  for  Function  Modelîng  0 
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7.1.2.13  Arbres  de  décision 


Un  arbre  de  décision  est  un  outil  d'aide. . .  à  la  décision  et  à  l'exploration  de  données.  Il  permet 
de  modéliser  simplement,  graphiquement  et  rapidement  un  phénomène  mesuré  plus  ou  moins 
complexe.  Sa  lisibilité,  sa  rapidité  d'exécution  et  le  peu  d'hypothèses  nécessaires  a  priori 
expliquent  sa  popularité  actuelle. 

MS  Office  Visio  n'est  pas  capable  de  faire  ce  genre  de  schémas  avec  les  calculs  associés  de 
manière  simple.  Il  faudra  typiquement  se  procurer  soit  TreeAge,  soit  Isograph  (déjà 
mentionnés  lorsque  nous  avons  présenté  des  logiciels  au  début  du  support),  soit 
Précision  Tree  de  Palisade  qui  permettent  non  seulement  de  mettre  de  probabilités  fixes  mais 
aussi  d'associer  à  chaque  branche  une  fonction  de  distribution.  Avec  TreeAge  pour  un  cas  à 
probabilité  fixe,  cela  donne: 


22.00 


oQjxj 


22.00;  P  =  0.34 


<  1.  DO.  P  =  0.12 


Lorsque  nous  avons  qu'une  seule  branche  dans  ce  type  d'arbore  avec  un  seul  gain  attendu  au 
bout,  nous  parlons  alors  de  "d'arbres  de  probabilités  pondérés"  (c'est  certainement  le  cas  le 
plus  courant). 

7.1.2.14  Options  réelles 

Lors  de  l'utilisation  d'arbres  pour  la  décision  dans  l'investissement  dans  des  projets  (nous 
parlons  alors  "d'analyse  d'investissement  par  options  réelles")  il  faut  prendre  en  compte  que 
chaque  série  parallèle  de  branches  représente  une  période  du  projet  (mois,  trimestre,  semestre 
ou  année).  Il  ne  faut  donc  pas  oublier  alors  d'actualiser  les  valeurs  aux  taux  de  rendement  sans 
risque  du  marché  correspondant  à  chaque  période.  De  plus  l'arbre  permet  aussi  de  calculer  la 
valeur  d'option  de  l'investissement,  ce  qui  est  parfois  demandé  par  la  direction. 

Effectivement,  considérons  la  situation  à  une  période  suivante: 
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Dans  un  logiciel  cela  donnera  typiquement  (malheureusement  les  coûts  des  options  sont 
toujours  cachés  dans  le  total  de  la  branche  dans  les  logiciels  spécialisés,  raison  pour  laquelle 
je  préfère  dessiner  mes  propres  arbres  dans  Microsoft  Excel): 


Alors  nous  avons  bien  évidemment: 

E  (Pay-Off  )  =  -12  +  0.75  •  (30  -  4  +  2)  +  0.25  •  (6  -  0.5  +  0.8) 
=  -12  +  0.75  •  32  +  0.25  •  6.3  =  13.575 

Car  l'arbre  se  réduit  à: 
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Mais  qu'en  est-il  de  la  valeur  actuelle  nette  (VAN/N.P.V)?  Eh  bien  ce  type  de  logiciels  nous 
permettent  facilement  d'intégrer  ce  type  de  calcul  avec  ou  sans  simulation  de  Monte-Carlo. 
Ainsi,  si  le  taux  sans  risque  du  marché  est  à  10%  sur  un  an,  nous  avons  alors  (voir  le  chapitre 
concernant  l'eVAN  à  la  page  341  pour  les  explications  techniques): 


0.75 -32 +  0.25 -6.3 
eVAN  =  -12  + - - - 

d  +  10%)1 


11.25 


Maintenant  il  peut  être  intéressant  (même  exigé  par  la  direction!)  de  calculer  le  "prix  de 
l'option  d'investir".  Dans  la  configuration  pessimiste  notre  arbre  devient: 


Nous  avons  alors  pour  cette  configuration: 

T7/1A7  „  0.75 -20 +  0.25 -3.8 

eVAN  =  -12  + - - - 

d  +  10%)1 


3.95 


Le  prix  de  l'option  réelle  d'investissement  (expected  Option  Value)  est  alors: 

eOV  =  1 1.25  -  3.95  =  7.2M$ 

Nous  donnerons  d'autres  exemples  avec  des  détails  bien  plus  tard. 
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7.1.2.15  Tableau  de  bord  (dashboard) 


En  gestion  de  projets  ou  de  la  qualité,  un  tableau  de  bord  est  un  synoptique  permettant  en  un 
simple  coup  d'œil  d'avoir  un  résumé  graphique  et  colorié  indiquant  la  performance  et  le 
rendement  de  certains  éléments  dont  l'analyse  est  souhaitée. 
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Wekornc  back  Rtch  w*h  Keane,  Inc . 

Mountain  View  Hospital 

C  RCM  |  Financial  [  Cftcal  J  Keane  ) 

About  Configuration  StgrvOut 

[  |[  Adnmtoom  ||  AAI  ||  AA2 

|[  Akeuiofc  | 

VwwpoM  levai:  Corporote 

&\ 

MTD  Cash  Coftected 

_  0  Mgmt  Sun  _ 

0  Curie*  A/R  Day*  (w/Drl) 

s 

MTD  Cash  Collée  ted 


Management  Summary  for  Monday,  March  6,  2006 


MTD  Bad  Debt  W/0 


Ourrent  DNFB 
/A  6 

'é  ^ 


/  S0.964M  ^ 


) 


[Revenue 

MTD  I/P: 

MTD  O/P: 

MTD  ER: 

MTD  Total: 

YTD  I/P: 

YTD  O/P: 

YTD  ER: 

YTD  Total: 

|A/RCash  1 

MTD  Pmts: 

MTD  W/0: 

MTD  To  BD: 

MTD  From  BD: 
MTD  Other: 

MTD  Total: 

YTD  Pmts: 

YTD  W/0: 

YTD  TO  BD: 

YTD  From  BD: 
YTD  Other: 

YTD  Total: 

IDMFB  I 

I/P: 

0/P: 

ER: 

Total: 

lA/R  Summary  I 

Beginmng: 

Plus  Chrgs: 

Less  Cash: 

Ending  A/R: 

IB/D  Summary  | 

Beginmng: 

Less  Cash: 

Ending  B/D: 


$8,516,125.74 

$31,941,398,372.15 

$83.304.821.040.78 

$1 15,254,737,538.67 

$8,518,125.74 
$31,941, 398,372. 1S 
$99.244.391.804.13 

$131,194,308,302.02 


-$31,498.30 

$7,742.51 

.00 

.00 

$82,853,148,668,67 

$82,853,172,424.46 

$31,498.30 

$7,742.51 

.00 

.00 

-$81,699,057,236.62 

$81,699,081,692.41 


$116,297.65 

$327.00 

$72.00 

$116,696.65 


$3,172,421.58 

.00 

$3,172,421.58 


$4,041.56 

,00 

$4,041.56 


Ourrent  A/R  Days 


Ourrent  A/R  urtxlled 


Ourrent  Q-edit  Balances 
-500 


Le  lecteur  intéressé  à  vouloir  faire  des  tableaux  de  bord  dans  les  normes  pourra  se  reporter  à 
la  très  bonne  base  que  constitue  la  norme  NF  FD  X  50-171  (qui  est  utile  mais  d'un  niveau  très 
peu  élevé)  que  je  ne  peux  pour  des  raisons  évidentes  de  copyright  par  reproduire  ici.  Sinon,  à 
part  entrer  dans  les  mathématiques  de  la  méthode  Six  Sigma  (cartes  de  contrôles14)  l'outil  ne 
consiste  qu'à  utiliser  des  outils  du  niveau  de  l'école  obligatoire  et  un  stagiaire  ou  un  junior 
peut  alors  très  bien  faire  le  travail. 

En  lisant  la  norme,  le  lecteur  se  rendra  compte  qu'il  vaut  mieux  essayer  de  travailler  aux 
maximum  avec  des  taux  (pourcents)  afin  de  pouvoir  comparer  sur  des  volumes  /  objectifs  / 
changements  dont  la  base  n'est  initialement  pas  forcément  la  même  (donc  sans  unités). 

Pour  information  il  y  a  même  une  époque  quand  je  n'avais  rien  d'autre  à  faire  je  créais  des 
indicateurs  (c'était  amusant  et  enfantin).  Voilà  un  exemple  un  peu  tordu  mais  qui  était 
pratique  (bien  qu'incomplet). 

Début  de  l'exemple: 

Plutôt  que  d'avoir  une  bête  flèche  de  couleur  monochromatique  nous  pourrions  déjà  avoir  une 
flèche  avec  un  dégradé.  Ainsi: 


14  Cartes  X-S,  X-R,  -C,  -P,  -NP,  -G,  Leney,  CUSUM,  EWMA,  ARIMA...  se  référer  à  mon  livre  sur  les 
mathématiques  appliquées  pour  les  détails  sur  ces  cartes. 
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qui  indiquerait  une  valeur  actuelle  (valeur  ponctuelle  de  30'000  d'où  le  "k")  haussière  sachant 
que  la  dernière  valeur  était  baissière  (couleur  rouge).  Le  vert  indiquant  que  pour  la  prochaine 
période  nous  nous  attendons  à  une  hausse. 

Nous  pourrions  ainsi  avoir: 


Indiquant  que  la  valeur  actuelle  est  haussière  (valeur  ponctuelle  de  300  d'où  le  "d")  mais  que 
la  période  précédente  était  baissière  (d'où  le  rouge  en  bas)  et  la  prochaine  période  sera  aussi 
probablement  baissière. 

Nous  pourrions  alors  aussi  avoir  (nous  arrêtons  de  mettre  le  nombre  en  coin  car  c'est  toujours 
le  même  principe): 


Indiquant  deux  valeurs  haussières  successives  (le  vert  étant  la  période  précédente)  et  la 
prochaine  période  est  prévue  comme  étant  baissière. 

Maintenant  introduisons  de  la  volatilité  (car  c'est  important!).  Par  exemple: 

* 

signifierait  un  indicateur  à  faible  volatilité  (avec  valeur  actuelle  baissière,  valeur  précédente 
haussière  et  la  projection  baissière).  Et: 


signifierait,  indicateur  à  forte  volatilité,  avec  valeur  précédente  baissière,  valeur  actuelle 
baissière,  valeur  future  projetée  haussière. 
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Lsa  pointe  de  la  flèche  peut  avoir  encore  un  disque  de  couleur  pour  indiquer  si  l'objectif  du 
management  est  (ou  "reste")  atteint  ou  non  (vert:  ="ok",  rouge:  "pas  ok")  et  des  lignes  peuvent 
apparaître  pour  montrer  les  limites  USL/LSL  ou  de  la  WECO  du  type  (inspiration  des  cartes 
de  contrôle): 


* 

Fin  de  l'exemple...  (quand  on  pense  que  la  majorité  des  entreprises  paient  des  cols  blancs  pour 
faire  des  indicateurs  avec  des  relativement  hauts  salaires  salaires  alors  qu'un  enfant  pourrait 
le  faire  aussi...  j'ai  toujours  eu  de  la  peine  à  comprendre  le  raisonnement  des  entreprises  à  ce 
niveau  là...?). 

7.1.3  Optimisation  des  processus 

Nous  n'allons  pas  aborder  ici  l'optimisation  des  processus  (business  process  reengineering) 
dans  le  sens  de  leur  clarté,  leur  standardisation  conformément  aux  normes,  à  l'identification 
des  étapes  inutiles  ou  manquantes  qui  sont  tous  trois  accessible  à  toute  personne  possédant  un 
peu  de  bon  sens  et  de  temps. 

Ce  qui  pose  problème  depuis  le  début  du  20eme  siècle  et  la  mesure  quantitative  (dans  le  sens 
scientifique  du  terme)  de  l'efficacité,  on  parle  dans  la  statistique  de  "capabilité",  d'un 
processus  et  de  l'analyse  numérique  de  la  variation  de  sa  performance  dans  le  temps  et  de  sa 
volatilité.  C'est  ce  dont  à  quoi  nous  allons  nous  attarder  ici. 

Comme  nous  l'avons  vu  dans  le  cours  de  Statistiques,  la  loi  Normale  est  une  fonction  en 
forme  de  "cloche"  donnée  dans  le  cas  général  univarié  par: 


S  2^ 


dont  les  écarts-types  sont  utilisées  pour  donner  l'intervalle  de  probabilité  cumulée  de  se  situer 
dans  ces  bornes  centré  sur  la  moyenne  comme  représenté  ci-dessous: 
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Ceci  étant  rappelé,  nous  avons  également  présenté  dans  le  cours  AMDEC  les  probabilités 
conjointes  dans  le  cadre  de  Six  Sigma  (ISO  13053-1:2011)  pour  une  chaîne  de  processus  P 
connectés  en  série. 

Au  fait  les  processus  mentionnés  ne  sont  pas  forcément  des  processus  industriels  mais 
peuvent  être  assimilés  sous  des  hypothèses  identiques  à  des  processus  quelconques 
(administratifs,  procédures,  workflows,  etc.). 

Nous  avions  vu  que  la  probabilité  conjointe  (ou  cumulée)  est  appelée  dans  Six  Sigma  "Rolled 
Troughput  Yield"  (R.T.Y.)  ou  "Rendement  Global  Combiné"  (R.G.C.)  et  est  donnée  par  (voir 
mon  livre  de  Mathématiques  Appliquées): 


RTY  =  P 


i  y 


Par  exemple  l'application  de  la  relation  précédente  donne  pour  un  processus  série  en  4  étapes 
dont  la  fiabilité  est  de  90%  chaque  (vous  pouvez  imaginer  aussi  qu'il  s'agit  de  4  tâches  en 
séquence  d'un  projet!): 


Processus 


Rendement 


90%  90%  90%  90% 


RTY 

65.6% 
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nous  nous  retrouvons  au  final  avec  une  fiabilité  de  65.6%  soit  une  probabilité  cumulée  de 
défaut  pour  l'ensemble  du  processus  de  34.4% 15. 

Redonnons  le  tableau  au  pire  selon  Six  Sigma,  soit  le  tableau  en  procédé  non  centré  avec  une 
déviation  de  la  moyenne  de  +1.5cr  (donc  à  droite  mais  on  pourrait  prendre  à  gauche  et  les 
résultats  sont  les  mêmes)  par  rapport  à  la  cible  et  d'écart-type  unitaire  avec  USL  et  LSL 
symétriques  (ce  qui  restreint  toujours  le  champ  d'application): 


cp 

cpk 

Défauts  ( PPM) 

Niveau  de  qualité  Sigma 

Critère 

0.5 

0 

501350 

1.5 

Mauvais 

0.6 

0.1 

382572 

1.8 

0.7 

0.2 

27412 

2.1 

0.8 

0.3 

184108 

2.4 

0.9 

0.4 

115083 

2.7 

1 

0.5 

66810 

3 

1.1 

0.6 

35931 

3.3 

1.2 

0.7 

17865 

3.6 

1.3 

0.8 

8198 

3.9 

Limite 

1.4 

0.9 

3467 

4.2 

1.5 

1 

1350 

4.5 

1.6 

1.1 

483 

4.8 

1.7 

1.2 

159 

5.1 

1.8 

1.3 

48 

5.4 

1.9 

1.4 

13 

5.7 

2 

1.5 

3.4 

6 

Excellent 

où  nous  avons  démontré  dans  le  cours  Six  Sigma  (ou  voir  mon  ouvrage  sur  les  mathématiques 
appliquées  pour  la  démonstration)  que  les  valeurs  PPM  étaient  données  par: 


™Tol  = 


USL  (x-M? 


1- 


2  dx 


■106  + 


V  / 

\ 


1 


LSL  (i-/i) 


2  \ 


je  2  dx 


•106 


L  J 

2n  1 


3  -Cf  (x-l.So)2 


2  dx 


■106  + 


1 

ijÏTT 


\  ~  / 
-3-(C,+l)  (i-1.5cr)3  '■ 


2  dx 


10e 


3-C, 


\ 


v. 


1-  J—  f  e  ^  dx 
V2 jt  1 


106  + 


J 


_L  f 
Æ  l 


3(C?+l)  _(x-1.5): 


2  \ 


dx 


10e 


15  Pour  le  cas  général  série/parallèle,  le  lecteur  pourra  sa  référer  à  mon  ouvrage  sur  les 
mathématiques  appliquées.  On  parle  alors  de  "AMDEC  processus". 
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Ce  qui  donne  pour  un  niveau  de  qualité  de  3  Sigma  en  utilisant  Maple: 

>evalf((  1  -  l/sqrt(2*Pi)*int(exp(-(x- 1 ,5)A2/2),x=- 

infinity..(l*3))))*lE6+evalf((l/sqrt(2*Pi)*int(exp(-(x-1.5)A2/2),x=-infinity..- 

(3*(1+1)))))*1E6; 

soit  une  valeur  de  66'810  c'est-à-dire  la  valeur  de  la  6ème  ligne.  Ce  qui  correspond  à  -6.68% 
en  termes  de  probabilité  cumulée  de  non-qualité  (66'8 10  divisé  par  1  million  et  mis  en 
pourcents)  et  donc  respectivement  à  une  probabilité  cumulée  de  -93.32%  de  qualité. 

Nous  avons  le  tableau  suivant  qui  peut  résumer  certaines  valeurs  importantes  du  tableau 
précédent  en  utilisant  la  commande  Maple: 


±3ct 

±4  CT 

±5  a 

±6  CT 

Qualité% 

93.32 

99.38 

99.98 

99.9996 

Çp 

1 

1.33 

1.68 

2 

Jugement 

Mauvais 

Limite 

Bon 

Excellent 

Une  vision  sympathique  de  la  chose  est  (je  n'ai  jamais  pu  vérifier  la  véracité  de  ces 
informations): 


3.8  Sigma 

6  Sigma 

Défaut  par  million 

ÎO'OOO  (1%  of  total) 

3.4  (0.00034%  of  total) 

Eau  potable 

1 5  minutes  d'eau  non  potable 
chaque  jour 

1  minute  non  potable  tous  les 

7  mois 

Erreurs 

5.000  erreurs  médicales  par  semaine 

1.7  opérations  ratées  par 
semaine 

Aéroport 

1  atterrissage  raté  par  jour 

1  atterrissage  raté  tous  les  5 
ans 

Électricité 

Pas  d'électricité  3  heures  par  mois 

Une  heure  de  coupure  tous  les 
34  ans 

La  Poste 

20'000  lettres  perdues  à  l'heure 

7  lettres  perdues  par  heure 

Sous  l'hypothèse  que  chaque  étape  d'un  processus  série  suit  la  même  loi  avec  les  mêmes 
moments  et  les  mêmes  déviations  par  rapport  à  la  cible  nous  avons  alors: 


Étapes/Qualité% 

±3  CT 

±4  CT 

±5  a 

±6  CT 

1 

93.32 

99.38 

99.98 

99.9996 

7 

61.63 

95.73 

99.84 

99.9976 

10 

50.08 

93.96 

99.77 

99.9966 
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20 

25.08 

88.29 

99.54 

99.9932 

40 

6.29 

77.94 

99.07 

99.9864 

60 

1.58 

68.81 

98.61 

99.9796 

80 

0.40 

60.75 

98.16 

99.9728 

100 

0.10 

53.64 

97.70 

99.996 

où  chaque  ligne  représente  le  Rolled  Troughput  Yield  donc  calculé  avec: 


/ 


RTY  =  P 


\  i 


où  i  est  donc  le  nombre  d'étapes  du  processus  (1,7,10,20,40)  et  où  les  probabilités  sont 
données  par  la  première  ligne  (1).  Ainsi,  avec  un  niveau  de  qualité  de  ±3cret  une  déviation  à 
la  cible  de  ±1.5cr  nous  avons  pour  un  processus  de  20  étapes  identiquement  distribuées: 


RTY  =  m=n  93.32%  =25.08% 

!  20 

Ce  qui  est  catastrophique!  On  comprend  donc  l'importance  d'avoir  un  haut  niveau  de  qualité 
sur  des  processus  complexes. 

Ainsi,  l'objectif  du  Lean  Six  Sigma  dans  une  entreprise  sera  d'augmenter  le  niveau  de  qualité 
avec  d'avoir  un  RTY  maximum  pour  un  nombre  donné  d'étapes  d'un  processus. 

Considérons  comme  exemple  pratique  le  cas  suivant: 
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Nous  avons  alors  une  probabilité  de  réussite  sur  l'ensemble  de: 


A 

1 

RTY 

2 

98% 

3 

85% 

4 

96% 

5 

99% 

6 

76% 

7 

99% 

8 

95% 

9 

=PRODUCT(A2:A8)=57% 

ce  qui  correspond  à  un  niveau  de  qualité  d'environ  3  sigma! 

Enfin,  pour  clore  se  sujet  et  pour  le  plaisir  voici  un  logigramme  (évidemment  pas  aux 
normes...)  assez  représentatif  parfois  ce  qui  se  passe  dans  la  réalité: 


Figure  9  Logique  de  traitement  des  incidents  (source:  ISBN  2708130226) 


Non 
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8.  Conduite  et  gestion  de  projets 

Si  votre  responsable  passe  vous  voir  et  vous  demande  de  superviser  un  projet,  c'est  qu'il  a 
partiellement  compris  qu'une  bonne  gestion  de  projets  peut  faire  gagner  (si  certaines 
hypothèses  sont  respectées)  du  temps  et  de  l'argent  dans  certaines  situations.  Comme 
plusieurs  millions  de  personnes  à  travers  le  monde,  il  vous  sera  demandé  d'utiliser  votre 
grande  expérience,  votre  habilité,  votre  leadership  et  votre  esprit  analytique  afin  de  permettre 
à  l'entreprise  de  croître  ou  simplement  de  continuer  à  prospérer. 

Si  vous  n'avez  jusque-là  jamais,  ou  pratiquement  pas,  suivi  de  formation  officielle  en  gestion 
de  projet,  ou  ne  n'êtes  pas  en  possession  d'une  diplôme  universitaire  dans  un  domaine 
particulier  sciences  exactes,  félicitations:  vous  voilà  devenu  gestionnaire  de  projets  par 
accident.  On  vous  a  sans  doute  confié  cette  fonction  parce  que  vous  êtes  fiable  (à  moins  qu'il 
y  a  des  attentions  moins  louables. . .)  et  que  vous  savez  organiser  votre  travail,  mais  vous 
n'avez  qu'une  vague  idée  de  ce  que  vous  êtes  censé  faire  ou  de  ce  qu'il  faut  faire  pour  réussir 
ou  obtenir  une  certaine  légitimité  de  vos  collègues  hautement  diplômés. 

La  gestion  de  projet  inclut  des  techniques  qui  sont  souvent  considérées  comme  simples  par  de 
nombreux  spécialistes.  Cependant  il  faut  savoir  que  cela  n'est  pas  une  généralité.  Plus  les 
projets  sont  gros,  plus  cela  nécessite  des  compétences  scientifiques  analytiques  pointues. 
Raison  pour  lesquelles  les  gros  projets  sont  souvent  donnés  à  des  personnes  provenant  du 
monde  financier  et  qui  ont  l'habitude  de  manipuler  des  équations  complexes.  Mais  dans  le 
cadre  de  petits  projets  (quelques  millions  de  francs)  cela  reste  simple  et  il  n'est  pas  nécessaire 
de  sortir  l'artillerie  lourde. 

Afin  de  tirer  le  maximum  d'un  projet,  il  est  impératif  pour  le  lecteur  de  bien  saisir  tous  les 
aspects  minimum  relatifs  à  la  culture  (très)  générale  de  la  gestion  de  projet.  Nous  discuterons 
donc  de  celle-ci  dans  cette  section,  en  élaborant  les  concepts  reliés  à  la  gestion  informatisée 
de  projet.  Nous  examinerons  aussi  les  facteurs  clés  de  succès,  de  manière  non  exhaustive,  que 
l'on  doit  toujours  considérer  dans  l'élaboration  d'un  projet. 

L'ensemble  des  éléments  acquis  ici  constitueront  une  partie  du  corps  des  connaissances  de 
base  du  gestionnaire  de  projet  (Project  Management  Body  Of  Knowledge  -  PMBOK)  qui 
selon  une  définition  internationale  par  le  PMI  (Project  Management  Institute)  est  donnée  en 
gros  par: 

«Le  PMBOK  inclus  les  connaissances  prouvées  et  généralement  acceptées,  ainsi  que  les 
pratiques  traditionnelles  qui  sont  largement  appliquées,  comme  des  méthodes  innovatrices  et 
avancées  de  pratiques  dans  la  gestion  de  projets  ». 

Cet  ensemble  de  pratiques  et  de  connaissances  est  accessible  dans  de  nombreux  ouvrages  et 
ne  nécessitent  aucunement  une  formation  de  haut  niveau.  Il  convient  cependant  de  préciser 
que  pour  des  projets  considérés  comme  sensibles  que  des  connaissances  d'un  tout  autre  niveau 
sont  nécessaires: 

■  Théorie  de  la  décision  (optimum  de  Pareto,  équilibre  de  Nash,  jeux  coopératifs,  jeux 
non-coopératifs,  critères  de  Laplace,  etc.) 
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■  Mathématiques  financières16  (escomptes,  amortissements,  spéculation,  économétrie, 
rentes,  emprunts,  retour  sur  investissement,  taux  internet  de  rentabilité  et  actuariel, 
équilibre  de  Cournot,  etc.) 

■  Statistiques  descriptives16  (moyenne,  médiane,  mode,  écart-type,  variance,  loi  de 
gauss,  courbe  de  Pareto,  loi  de  Poisson,  loi  Beta,  SPC  Six  Sigma,  etc.) 

■  Modélisation  du  choix  (modèles  de  logit  et  probit) 

■  Techniques  de  gestion16  (loi  de  Wilson,  droite  d'Henry,  PERT  probabiliste, 
estimateurs  empiriques,  loi  de  Weibull,  etc.) 

■  Algorithmique  (théorème  du  point  fixe,  méthode  de  Newton,  théorème  du  simplexe, 
recherche  opérationnelle,  méthode  Monte-Carlo,  théorie  des  graphes) 

■  Connaissances  pratiques  et  théoriques  à  jour  dans  le  domaine  applicatif  (veille 
technologique  et  économique) 

L'IPMA  quant  à  elle  définit  (est  c'est  un  excellent  point  de  vue)  les  compétences  d'un 
responsable  de  projet  dans  trois  domaines  bien  précis17  (le  "Eye  of  Compétence"): 

1.  Les  compétences  contextuelles  (propres  au  contexte  environnemental  du  projet) 

2.  Les  compétences  techniques 

3.  Les  compétences  comportementales 


Contextual 

compétences 


Behavioural  Y 
compétences  f  compétences 


Figure  10  Oeil  du  IPMA 


16  Voir  cours  "MS  Excel  Maths  financières"  avec  votre  formateur 

17  Dans  une  micro-conférence  donnée  une  fois  par  l'agence  de  placement  Adecco  sur  les  critères  de  sélection  d'un 
bon  responsable  de  projet,  on  retrouvait  ses  3  points. 
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Avec  les  détails  suivants  qui  constituent  aussi  un  excellent  référentiel!: 


Contextua!  compétences 

Project  orientation 
Programme  orientât  Ion 
Portfolio  orientation 

Project  programme  &  portfolio  implémentation 
Permanent  organisation  , 

^  Business  Æ 

System  Sj  products  &  technology  Æf 
Personnel  management 
Health,  securlty,  safety  // 

&  environment 
Finance 

Legal  Techni 


Behavioural  compétences 

Leadership 

Engagement  &  motivation 
Solfie  ont  ml 
Assertlveness 
Relaxation 
L  O  pennes  s 
L  Créât  lui  ty 
WL  Results  orientation 
Efflclency 
Tk  Consultation 
Negotiatlon 
Gonfllct  &  crlils 
Relkablllty 

Values  appréciation  j 
Et  h  i  es  i 


39ai|  Tech  n  ica  I  compétences 

Project  management  suteess 
mterested  parties 
Project  requliementf  &  objectives 
RI  ik  &  opportunity 

Quallty 
Project  organisation 
Teamwork 
Problem  résolution 
Project  structures 
Sc  ope  &  de!  lue  râbles 
Time  S-  proJect  phases 
Resources 
Cost  fb  finance 
Proprement  &  contract 
Changes 

Contrai  &  reports 
Information!  -Si  documentation 
Communication 
Start-up 
Close -eut 


Ainsi,  les  compétences  représentées  dans  la  figure  ci-dessous  peuvent  être  rangées  dans  une 
de  ces  catégories: 
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Remarque:  U  optimisation  sous  contrainte  inclus  également  les  contraintes  organisationnelles 
et  consiste  à  jouer  avec  les  3  critères  habituels:  délais  -  coûts  -  qualité  pour  arriver  aux 
objectifs.  Par  exemple,  si  la  contrainte  est  de  type  "hiérarchique"  (conflits  organisationnels 
internes)  il  faut  essayer  de  responsabiliser  les  supérieurs  pour  résoudre  le  problème  ou 
proposer  des  choix  à  ceux-ci  et  de  prendre  la  décision  sous  couverture  d'un  papier  signé  qui 
valide  l'acceptation  du  choix. 

Depuis  déjà  plusieurs  décennies,  la  gestion  de  projet  a  contribué  de  façon  très  significative  à 
la  nouvelle  pratique  de  la  gestion.  Grâce  à  cette  approche,  les  organisations  peuvent  un  peu 
mieux  planifier,  coordonner,  diriger  et  surtout  contrôler  leurs  ressources  et  ce,  de  façon 
structurée  et  optimale.  En  effet,  la  gestion  informatisée  de  projet  procure  un  outil  très  puissant 
aux  gestionnaires  d'aujourd'hui  par  sa  flexibilité  et  sa  polyvalence.  De  plus,  elle  devrait 
permettre  de  résoudre  les  problèmes  les  plus  complexes. 

La  philosophie  de  la  gestion  de  projets  permet  donc  de  faire  face  à  des  défis  jadis 
insurmontables  pour  les  administrations  traditionnelles.  Il  s'agit  d'une  méthodologie  avant- 
gardiste  répondant  à  un  monde  de  plus  en  plus  complexe  et  dynamique.  Elle  répond  à  un 
besoin  pressant  de  faire  travailler  ensemble  les  ressources  multidisciplinaires  dans  l'atteinte 
d'un  but  commun.  Elle  génère  la  créativité,  l'initiative  et  l'empowerment  vis-à-vis  des 
membres  de  l'équipe  de  projet. 

Plusieurs  définitions  de  la  gestion  de  projet  existent  un  peu  partout  dans  la  littérature 
académique.  J.R.  Meredith  et  S.  Mantel,  dans  leur  ouvrage  «Project  Management»  la 
définissent  comme  étant: 

«la  gestion  des  interfaces  entre  la  performance,  le  temps  et  les  coûts» 


Ou  selon  l'AFNOR: 


«La  gestion  de  projet  est  l'ensemble  des  méthodes,  outils  d'évaluation,  de  planification  et 
d'organisation  permettant  d'atteindre  ses  objectifs  en  respectant  les  contraintes  de 
performance,  de  délais,  et  de  coûts.» 

Ou  selon  le  PMBOK  version  4.0: 


«A  project  is  a  temporary  endeavour  that  is  progressively  planned,  controlled  and  executed  by 
people,  working  with  some  constraints  on  resources  that  results  in  a  unique  product  service  or 
resuit  that  isn't  possible  for  the  organization  to  achieve  through  its  normal  operations.» 


Ingénierie  de  Gestion  de  projets 


139/547 


Ou  selon  le  PM2: 


«A  project  is  a  temporary  organisational  structure  which  is  setup  to  create  a  unique  product  or 
service  (output)  within  certain  constraints  such  as  time,  cost,  and  quali ty.» 


Temporary 


Start  &  End 


Non  routine  Product  or  Service  Time,  Cost,  Quality... 


En  fait,  la  gestion  de  projet  nous  permet  de  livrer  un  bien  et/ou  un  service  de  qualité  à  la 
bonne  place,  au  bon  moment,  à  la  bonne  personne  et  au  meilleur  coût  possible.  C'est  donc  une 
activité  généralement  isolée  comportant  des  objectifs  très  bien  définis. 


Un  projet  est  souvent  l'effet  d'une  cause  qui  est: 

-  Une  demande  du  marché 

-  Une  demande  d'un  client  (interne  ou  externe) 

-  Une  opportunité  stratégique 

-  Une  évolution  suite  à  un  changement  de  l'environnement  (légal,  social,  technologique) 

Certains  auteurs  ont  une  approche  "systémique"  de  la  gestion  de  projets.  C'est-à-dire  une 
approche  "système"  incluant  généralement  un  ensemble  de  structures  actives  inter-reliées  par 
des  entrées  et  sorties  et  qui  peuvent  être  également  considérées  elles-mêmes  comme  systèmes, 
ayant  une  finalité  (objectif)  commune.  Traditionnellement  trois  structures  sont  considérées 
sous  le  nom  de  Approche  Systématique  des  Systèmes: 


Environnement 


Entreprise  /  Organisation 


I 


Système  d'information 


-  Mémorise 

-  Traite 

-  Diffuse 


; 

Information 


Flux  Primaires  Système  Opérant 


Matière,  -  Produit 

Finance, 

Personnel, 

Information 


-  Transforme 


> 
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Le  PM2  définit  aussi  très  bien  le  concept  de  programme  comme  un  groupe  de  projets  réunis 
dans  le  but  de  faciliter  la  gestion  et  d'atteindre  des  objectis  et  bénéfices  qui  n'auraient  pas  été 
possibles  si  les  projets  avaient  été  gérés  individuellement. 

Toujours  selon  le  PM2,  une  gestion  de  programmes  diffère  d'une  gestion  "multi-projets". 
Effectivement  ce  dernier  cas  étant  la  gestion  de  projets  qui  n'intérférent  pas  entre  eux  et  dont 
la  gestion  parallèle  n'apport  aucune  bénéfice  significatif. 


Strategie  Planning 


Strategie 


Objectives 


Operations 
(Everyday  Work) 


Portfolio  Management 


Programme/Project 

Management 


8.1  Petit  historique  de  la  gestion  de  projets 

La  gestion  de  projets  par  progiciel  fait  appel  à  un  certain  nombre  de  techniques  dont  il  est 
intéressant  de  connaître  un  petit  historique  et  les  éléments  principaux: 

•  En  1917,  Henry  L.  Gantt,  ingénieur  américain  assistant  de  Frederick  Taylor  (ingénieur 
et  économiste  américain  de  l'organisation  scientifique  du  travail  O.S.T),  doit  organiser 
la  production  d'un  atelier.  Dans  ce  but,  il  développe  un  système  de  représentation 
graphique  des  activités  sur  une  échelle  de  temps:  le  diagramme  à  barres.  Aujourd'hui, 
on  parle  de  "Diagramme  de  Gantt"  (Gantt  Chart) 

•  En  1928  le  mathématicien  John  Von  Neumman  reprend  les  travaux  du  17eme  siècle  sur 
la  théorie  des  jeux  sous  un  formalisme  mathématique  moderne.  Une  dizaine  d'années 
plus  tard,  cette  théorie  sera  avec  les  améliorations  de  John  Nash  (Prix  Nobel 
d'Economie)  à  la  base  de  toutes  les  décisions  en  entreprise  ou  en  économie  à  l'échelle 
mondiale. 

•  En  1940,  les  physiciens  et  les  mathématiciens  créent  les  bases  des  techniques 
quantitatives  statistiques  de  la  gestion.  La  méthode  de  Monte  Carlo,  initialement 
élaborée  par  les  mathématiciens  Nicholas  Metropolis  et  Stanislaw  Ulam  en  1949,  a  été 
utilisée  à  cette  époque  pour  le  projet  Manhattan  aux  laboratoires  de  Los  Alamos.  Elle 
est  utilisée  à  outrance  aujourd'hui  dans  la  gestion  des  risques  et  la  théorie  du  choix  à 
avenir  incertain. 
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•  Dans  les  années  1940  William  Edwards  Deming,  Statisticien,  mondialement  connu 
pour  sa  méthode  PDCA  (Plan  Do  Check  Act)  développe  les  techniques  mathématiques 
statistiques  dans  le  domaine  de  la  gestion  de  projets  en  se  basant  sur  les  travaux 
mathématiques  de  Walter  Shewhart  développés  dans  les  années  1920: 


Amélioration  de 
la  qualité  affective 


Consolidation  du  niveau  atteint 
Base  de  référence  =  Reference  Baseline 


i 

Echelle  de  temps 


Le  PDCA  vise  donc  à  l'amélioration  continue  comme  objectif  permanent  et  en  stabilité 
le  niveau  de  consolidation  atteint.  Mais  pour  appliquer  correctement  cette  méthode  (au 
même  titre  que  ISO  9001),  il  faut  définir  le  périmètre  d'activités  qui  sera  analysé  et 
amélioré,  découper  le  périmètre  en  processus  (cartographie  des  processus)  et 
formaliser  chacun  des  processus  (activités,  intrants,  extrants,  rôles,  compétences,  etc.). 

•  Dans  les  années  1950,  les  sociétés  Dupont  de  Nemours  et  Remington  Rand  cherchent 
une  technique  qui  permette  de  gérer  au  mieux  un  grand  nombre  de  tâches  liées  entre 
elles.  En  56/57,  Morgan  Walker  et  James  Kelley  mettent  au  point  un  algorithme  de 
calcul  par  des  mathématiciens,  le  CPM  (Critical  Path  Method).  Il  permet  de  calculer  la 
durée  totale  d'un  projet  à  partir  de  la  durée  de  chaque  tâche  et  des  liaisons  existant 
entre  les  différentes  activités  du  projet. 

Parallèlement  au  CPM,  la  méthode  PERT  (Program  Evaluation  and  Review  Technic) 
est  créée  par  la  marine  américaine  pour  l'élaboration  de  ses  missiles  Polaris.  Cette 
technique  met  graphiquement  en  évidence  les  relations  entre  les  tâches  hors  du  temps. 

•  Dès  1958,  le  calcul  mathématique  du  CPM,  abrégé  CP  (Critical  Path),  est  appliqué  au 
PERT.  Par  ce  raisonnement,  toute  modification  de  la  durée  d'une  tâche  située  sur  ce 
chemin  entraîne  une  modification  dans  la  date  de  fin  du  projet. 

Adoptée  par  la  marine  américaine,  cette  dernière  estime  n'avoir  passé  que  5  ans  sur  le 
projet  Polaris  au  lieu  des  7  prévues. 

•  En  1965,  première  utilisation  de  Monte-Carlo  appliquée  à  la  gestion  de  projets  par  le 
statisticien  R.M.  Vanslyke. 

•  En  1970,  le  statisticien  A.V.  Feigenbaum  et  le  chimiste  K.  Ishikawa  élaborent  ce  qui 
sera  plus  tard  le  "Total  Quality  Control". 
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•  En  1995,  le  physicien  E.  M.  Goldratt  publie  un  article  sur  la  fameuse  Critical  Chain  et 
Theory  of  Contraints  (TOC). 

•  Depuis  2010  seulement,  les  techniques  de  modélisation  et  simulation  stochastique  du 
risque  sont  enseignées  dans  certaines  universités  en  Suisse... 

•  Aujourd'hui  on  conjugue  les  trois  techniques.  Un  Gantt  affiche  les  relations  entre  les 
tâches  (ainsi  que  le  réseau  PERT  mais  hors  du  temps)  et  peut  aussi  afficher  le  chemin 
critique  (méthode  CPM). 

Nous  pouvons  donc  constater  que  toutes  les  techniques  et  outils  de  pointe  ont  été  créés  par  des 
scientifiques  de  haut  vol  (et  nous  pourrions  encore  citer  le  physicien  Eliyahu  Moshe  Goldratt, 
le  statisticien  Pareto,  le  statisticien  Joseph  Juran,  le  mathématicien  Gauss,  etc.).  In  extenso, 
nous  pouvons  nous  demander  s'il  est  judicieux  de  laisser  des  personnes  qui  n'ont  pas  de  profil 
scientifique  s'occuper  de  projets  complexes  ou  d'analyser  la  qualité  dans  les  entreprises... 
(sachant  que  le  niveau  des  MBA  et  EMBA  est  misérablement  bas  relativement  aux 
mathématiques  puisqu'il  ne  dépasse  pas  la  deuxième  année  de  licence). 

8.2  Intervenants 

Il  n'y  a  qu'un  patron  :  le  client.  Et  il  peut  licencier  tout  le  personnel,  depuis  le  directeur  jusqu'à 
l'employé,  tout  simplement  en  allant  dépenser  son  argent  ailleurs.  (Sam  VJalton) 

Pour  répondre  aux  questions  posées  et  satisfaire  la  demande,  de  nombreux  intervenants  sont 
consultés  lors  de  la  modélisation  d’un  projet  ou  de  l’exécution  de  celui-ci  (il  faudrait  vous 
positionner  parmi  ceux-ci).  Voici  la  liste  de  quelques-uns  de  ceux-ci: 

Le  Maître  d'ouvrage: 

Personne  physique  ou  morale  qui  sera  propriétaire  de  l'ouvrage  réalisé.  Plus 
communément  appelé  le  "client". 
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CUSTOMERS 

CUSTOMERS  are  the  most  important 
people  in  our  company 

CUSTOMERS  deserve  our  courteous 
and  attentive  treatment 

CUSTOMERS  do  not  interrupt  our 
work;  they  are  the  purpose  of  it 

CUSTOMERS  bring  us  their  needs; 
it  is  our  job  to  fulfill  them 

CUSTOMERS  are  part  of  our 
company;  they  are  not  outsiders 

CUSTOMERS  do  not  dépend  on  us; 
we  dépend  on  them 

CUSTOMERS  “ARE”  our  business 

Le  Maître  d'œuvre: 

Personne  physique  ou  morale  qui  réalise  le  travail  pour  le  maître  d'ouvrage. 

Le  Sponsor  du  projet/Project  Champion: 

Gestionnaire  senior  ayant  un  pouvoir  décisionnel  supérieur  à  celui  de  project  ou 
portfolio  manager  et  étant  en  relation  étroite  avec  la  direction  pour  faire  accepter  le 
projet  qui  est  en  phase  d'études  et  faire  comprendre  à  la  direction  l'intérêt  de  le  gérer 
selon  des  méthodes  standardisées  et  éprouvées.  Si  le  sponsor  n'a  pas  le  temps  de  gérer 
le  projet  et  n'est  pas  assez  compétent  pour  motiver  l'équipe  de  projet,  il  pourra 
déléguer  cette  tâche  à  une  autre  personne  qu'on  désignera  alors  par  le  terme  "project 
champion". 

Le  Chargé  d'affaires/Portfolio  Manager: 

L'affaire  est  une  demande  ou  un  besoin  exprimé  par  un  Client  (ou  un  Prospect).  Le 
chargé  d'affaires  assure  les  contacts  avec  le  maître  d'ouvrage  avant  la  conclusion  du 
contrat,  pendant  son  déroulement  et  lors  de  son  achèvement  ainsi  qu'après  (contrat  de 
clôture  équivalent  à  un  bon  de  réception).  Le  chargé  d'affaires  gère  plusieurs  projets 
qui  n'ont  strictement  aucune  relation  entre  eux  (il  s'agit  de  la  définition  d'un  "portfolio" 
de  projets). 

Le  Responsable  de  programme/Program  Manager 
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Personne  qui  supervise  un  projet  qui  a  été  découpé  en  plusieurs  sous-projets  dû  à  la 
complexité  de  la  tâche. 

Le  Coordinateur  de  projet/Project  Manager: 

L'A.F.NOR  (Association  Française  de  Normalisation)  nous  donne  la  définition 
(légère...)  suivante:  " personne  physique  chargée  dans  le  cadre  d'une  mission  définie, 
d'assumer  la  maîtrise  du  projet,  c'est-à-dire  de  veiller  à  sa  bonne  réalisation  dans  les 
objectifs  de  technique,  de  coût  et  de  délai" . 

Le  Responsable  planification/Scope  &  Time  Manager: 

Il  identifie  et  organise  les  tâches,  publie  l'échéancier  de  chaque  activité;  ensuite,  il  met 
à  jour  le  planning  et  calcule  la  probabilité  que  les  délais  soient  maintenus.  Souvent,  le 
coordinateur  de  projet  assume  cette  fonction. 

Le  Responsable  de  département/Team  leader  (Operation  Manager): 

C'est  le  garant  d'un  des  savoir-faire  de  l'entreprise.  Il  est  sollicité  par  le  coordinateur  de 
projet  à  qui  il  doit  fournir  les  moyens  en  rapport  avec  son  métier  et  son  expertise. 
Attention  à  ne  pas  confondre  les  "Operation  Managers"  avec  les  "Functional 
Managers",  ces  derniers  étant  un  cas  particulier  du  premier  dans  le  domaine  de 
l'administration  ou  de  l'immatériel  (cols  blancs  VS  cols  bleus). 

La  Ressource/Resource: 

Partie  intégrante  de  "l'équipe  de  projet",  elle  est  informée  et  animée  par  son 
responsable  de  département.  Son  travail  est  géré  et  validé  par  son  responsable 
hiérarchique. 

Le  Directeur  Qualité/Quality  Manager: 

La  gestion  de  projets  s'inscrit  dans  une  démarche  qualité  dont  l'importance  va  en 
augmentant  (Risk  Management).  Les  outils  mathématiques  sont  à  ce  niveau 
indispensables. 

Le  Contrôleur  de  Gestion/Cost  Manager: 

Le  coût  est  l'un  des  trois  piliers  de  la  gestion  de  projet  (Qualité  -  Coûts  -  Délais),  d'où 
l'importance  de  ce  rôle.  Les  outils  mathématiques  sont  aussi  à  ce  niveau 
indispensables. 

Le  Business  Analyst  (B.A.) 

C'est  la  personne  dédiée  à  analyser  les  contraintes,  à  identifier  les 
besoins/buts/objectifs,  les  exigences  environnementales/interfaces/opérationnelles  et 
qualitatives,  les  moyens  de  communications,  les  outils  centralisés  et  intègres  de 
gestion  de  projets,  les  risques,  la  volatilité,  les  bons  intervenants  et  c'est  aussi  le 
business  analyst  qui  met  en  relation  les  différents  intervenants  du  projet  avant  que 
celui-ci  commence  et  qui  s'occupera  de  gérer  le  changement  (change  request)  à  l'aide 
d'un  "change  request  board".  Le  B.A.  participera  également  à  la  validation  du 
prototype/pilote  (version  alpha  ou  beta)  s'il  y  en  a  un  (voir  le  BABOK  pour  plus 
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d'informations).  En  réalité,  c'est  le  B.A.  qui  rédigera  une  bonne  partie  du  cahier  des 
charges  à  lui  seul. 
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Le  Responsable  Juridique 

C'est  la  personne  de  référence  qui  s'assurera  que  sur  l'ensemble  du  projet  il  n'y  ait  pas 
d'outils  ou  de  contrats  qui  ne  soient  pas  conformes  à  la  législation  en  vigueur. 

Le  cas  le  plus  typique  et  demandé  en  formation  (mais  ultra-basique...)  c'est  de  savoir 
quel  système  de  jours  de  congé  doit  être  pris  lorsqu'un  consultant  part  à  long  terme 
dans  un  pays  étranger.  Normalement  on  fait  un  avenant  juridique  temporaire  au  contrat 
de  travail  avec  une  clause  d'adaptation  aux  jours  non  fériés  du  pays/région  cible. 

Le  Project  Management  Office  (PMO) 

Il  s'agit  d'une  organisation  à  l'intérieur  d'une  entreprise  à  laquelle  des  responsabilités 
diverses  reliées  à  la  gestion  de  projets  centralisée  et  à  la  coordination  du  management 
sont  assignées.  Les  fonctions  type  d'un  PMO  sont  (selon  le  PMI/PMBOK  V4)  de  gérer 
les  ressources  entre  les  projets,  de  définir  les  standards,  meilleurs  pratiques  et 
méthodologies  pour  toute  l'entreprise,  de  former  les  intervenants  du  projet  et 
responsables  de  projets,  de  développer  les  règles,  procédures  et  modèles  ou  toute  autre 
documentation  relative  à  la  gestion  de  projets  de  projets  et  de  coordonner  la 
communication. 

Le  Fournisseur 

Il  convient  de  distinguer  le  fournisseur  de  services  qui  est  une  organisation  qui 
fournit  des  services  à  un  ou  plusieurs  clients  internes  ou  externes  du  fournisseur 
externe  qui  est  une  tierce  partie,  responsable  de  la  fourniture  d'éléments  sous-traités 
(biens  ou  services)  nécessaires  à  la  fourniture  de  bien. 

Un  petit  schéma  proposé  par  le  référentiel  ITIL  bien  pratique  (mais  logique...)  pour 
catégoriser  les  fournisseurs: 
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Risque  et  impact 


Au  niveau  du  responsable  de  projet,  voici  un  tableau  empirique  résumant  les  niveaux  (d'après 
mon  expérience  personnelle  rencontrée  dans  les  entreprises)  uniquement  en  ce  qui  concerne 
les  responsables  de  projets: 
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Titre 

Budget 

Nombre  de  ressources 

Assistant  de  projets  ou  "white  belt" 
Condition  minimale: 

Certificat  de  fin  d'études  obligatoires 

Particularités: 

-  Travaille  seul  pour  gérer  le  micro-projet  et 
n'a  pas  de  pouvoir  décisionnel  sur  les 
finances. 

-Applique  des  méthodes  minimalistes  afin 
que  la  gestion  de  projets  pure  ait  un  coût 
minimal. 

-N'a  pas  d'outil  de  gestion  de  projets 
particuliers  (utiliser  un  tableur  et  un  agenda) 

-  Consacre  -10%  de  son  temps  total  à  la 
gestion  de  projets. 

0-20'000$ 

0-5 

Responsable  projets  junior  ou  "yellow 
belt” 

Conditions  minimales: 

Certification  internationale  en  gestion  de 
projets  avec  au  moins  5  ans  d'expérience 

Particularités: 

-  Travaille  seul  pour  gérer  le  projet  et  peut 
proposer  à  la  hiérarchie  un  budget. 

-  Connaît  les  méthodes  de  gestion  de  projets 
mais  n'en  applique  qu'une  partie,  sans 
respecter  des  processus  éprouvés. 

-  N'a  pas  d'outil  de  gestion  de  projets 
particuliers  (utiliser  un  tableur  et  un  agenda). 

-  Consacre  -50%  de  son  temps  total  à  la 
gestion  de  projets. 

20'000$-100'000$ 

5-10 

Responsable  projets  ou  "green  belt" 
Conditions  minimales: 

Licence  universitaire  avec  au  moins  10  ans 
d'expérience 

Particularités: 

-  Travaille  dans  une  équipe  de  2  à  4 
personnes  dédiées  uniquement  à  de  la  pure 
gestion  du  projet. 

-  Connaît  les  méthodes  de  gestion  de  projets 
et  en  applique  une  partie  en  respectant 
quelques  processus  simples. 

-  A  des  outils  de  gestion  de  projets  basiques 
(planificateur,  système  électronique  de 
gestion  de  la  documentation) 

-  Consacre  100%  de  son  temps  total  à  la 
gestion  de  projets 

100'000$  à  15M$ 

10-200 

Responsable  de  projet  senior  ou  "blue 
belt" 

Conditions  minimales: 

Licence  universitaire  avec  certification 
internationale  en  gestion  de  projets 

Particularités: 

-  Travaille  dans  une  équipe  de  4  à  9 
personnes  dédiée  à  la  gestion  du  projet 
conformément  aux  pôles  de  compétences 
décrits  par  le  PMBOK. 

-  Connaît  les  méthodes  de  gestion  de  projets 
et  les  applique  en  respectant  des  processus 
éprouvés. 

-  A  des  outils  de  gestion  de  projets  avancés 

15M$  à  500M$ 

200-1500 

Ingénierie  de  Gestion  de  projets 


148/547 


Vincent  ISOZ 


Titre 

Budget 

Nombre  de  ressources 

(planificateur  centralisé,  système 
électronique  de  gestion  de  la  documentation 
avec  workflows,  système  de  gestion  de  la 
qualité  et  des  risques) 

-  Consacre  100%  de  son  temps  total  à  la 
gestion  de  projets 

Responsable  expert  de  projets  ou  "red 
belt" 

Conditions  minimales: 

Maîtrise  universitaire  avec  certification 
internationale  en  gestion  de  projets  et  au 
moins  15  ans  d'expérience 

Particularités: 

-  Travaille  dans  une  équipe  structurée  en 

PMO  dédiée  à  la  gestion  de  projets  d'entre 

10  et  50  personnes  conformément  à  la 
majorité  des  standards  de  gestion  (PMBOK, 
Six  Sigma,  BABOK). 

-  Connaît  les  méthodes  de  gestion  de  projets 
et  les  applique  en  respectant  des  processus 
éprouvés  et  optimisés. 

-  A  des  outils  de  gestion  de  projets  avancés 
(planificateur  centralisé,  système 
électronique  de  gestion  de  la  documentation 
avec  workflows,  système  de  gestion  de  la 
qualité  et  des  risques)  et  d'aide  à  la  décision 
(modélisation  du  risque  et  arbres 
décisionnels). 

-  Propose  les  instruments  financiers  pour  se 
protéger  des  variations  (options,  futures, 
forex,  etc.) 

-  Consacre  100%  de  son  temps  total  à  la 
gestion  de  projets 

500M$  à  5B$ 

1500-10'000 

Responsable  maître  de  projets  ou  "black 
belt” 

Conditions  minimales: 

Master/Doctorat  universitaire  ou  équivalent 
dans  un  domaine  des  sciences  exactes  et  au 
moins  20  ans  d'expérience  en  gestion  de 
projets. 

Particularités: 

-  Travaille  dans  une  équipe  structurée  en 

PMO  dédiée  à  la  gestion  de  projets  de  plus 
de  50  personnes  conformément  à  la  majorité 
des  standards  de  gestion  (PMBOK,  Six 

Sigma,  BABOK). 

-  Connaît  les  méthodes  de  gestion  de  projets 
et  les  applique  en  respectant  des  processus 
éprouvés  et  optimisés. 

-  A  des  outils  de  gestion  de  projets  avancés 
(planificateur  centralisé,  système 
électronique  de  gestion  de  la  documentation 
avec  workflows,  système  de  gestion  de  la 
qualité  et  des  risques)  et  d'aide  à  la  décision 
(modélisation  du  risque  et  arbres 
décisionnels)  le  tout  connecté  en  temps  réel 
à  un  ERP. 

-  Gère  les  instruments  financiers  pour  se 
protéger  des  variations  (options,  futures, 

>5  milliard  de  $  (5B$) 

>10’000 
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Titre 

Budget 

Nombre  de  ressources 

forex,  etc.) 

-  Consacre  100%  de  son  temps  total  à  la 
gestion  de  projets 

Tableau  3  Niveaux  de  responsables  de  projets 


Bien  évidemment  il  ne  faut  utiliser  adapter  ses  méthodes  de  gestion  au  contexte.  On  va  pas 
utilier  des  méthodes  Agiles  pour  un  projet  à  haute  technicité  pour  lesquelles  des  vies  sont  en 
jeu  et  on  va  pas  utiliser  des  méthodes  de  gestion  scientiques  pour  un  projet  consistant 
consistant  à  rénover  les  toilettes  d'un  stade  de  football. . .  En  bref  comme  j'aime  souvent  dire: 


Outre  les  intervenants,  signalons  également  les  domaines  de  connaissance  de  la  gestion  de 
projets  et  quelques  processus  y  relatifs  par  le  diagramme  synoptique  de  la  page  suivante  pris 
de  l'excellent  référentiel  de  base  que  constitue  le  PMBOK. 

Remarque:  MS  Office  Project  ne  peut  pas  englober  l'ensemble  des  outils  dont  peuvent  avoir 
besoin  ces  différents  corps  de  métier. 
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Figure  11  Métiers  de  la  gestion  de  projets 


ou  selon  la  structure  de  MS  Project  Server  nous  la  hiérarchie  suivante: 


Ingénierie  de  Gestion  de  projets 


151/547 


Vincent  ISOZ 


Project  Portfolio  Manager 

Project  Managers 


Team  Leaders 


Ressources 


Remarque :  La  gestion  de  projets  ne  peut  pas  se  satisfaire  d'une  structure  de  type  "Lead 
Management"  ou  chaque  collaborateur  est  indépendant.  La  meilleure  structure  à  ce  jour  reste 
la  hiérarchie  traditionnelle. 

Le  coordinateur  de  projets  (responsable  de  projet)  ne  doit  surtout  pas  oublier  avant  que  nous 
allions  plus  loin  les  3  points  suivants  concernant  les  ressources: 

1.  Très  rarement  disponibles  réellement  à  100%:  par  convention  80%  en  ce  qui  concerne 
les  personnes,  pour  les  machines  on  utilise  le  taux  de  rendement  synthétique  (ou  plus 
simplement  l'adéquation  capacité/charge) 

2.  Ont  un  profil  de  travail  de  type  Bêta  en  ce  qui  concerne  les  personnes 

3.  Ont  des  vacances  et  des  jours  de  congé  maladie  dans  une  année. . .  en  ce  qui  concerne 
les  personnes  et  des  temps  de  panne  et  de  maintenance  en  ce  qui  concerne  les 
machines! 

lorsqu'il  planifie  les  détails  d'un  nouveau  mandat! 

8.3  Types  de  responsables  de  projets 

Nous  pouvons  essayer  de  catégoriser  par  l'expérience  vécue  les  responsables  de  projets  dans 
différentes  catégories: 

•  Le  responsable  de  planification  (ne  gère  pas  les  coûts  et  la  qualité) 

•  Le  responsable  de  projets  improvisé  (apprend  par  l'erreur  mais  n'en  est  pas 
responsable) 

•  Le  responsable  de  projets  autoproclamé  (apprend  par  l'erreur  et  en  est  responsable) 
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Le  responsable  de  projets  certifié  (a  eu  la  bonne  initiative  d'éviter  de  découvrir  les 
erreurs  classiques  en  suivant  des  formations  adaptées) 

L'ingénieur  en  gestion  de  projets  diplômé  (a  une  formation  de  plusieurs  années  dans 
l'ensemble  du  cercle  vertueux  de  la  gestion  de  projet  en  utilisant  des  outils  et 
techniques  mathématiques  élaborées) 

Le  docteur  en  gestion  de  projets  (a  un  doctorat  dans  le  domaine  et  fait  de  la  R&D 
pour  résoudre  des  problèmes  complexes  à  l'aide  de  méthodes  scientifiques) 

Enfin  nous  pouvons  aussi  considérer  3  niveaux  de  compétences  pour  un  responsable  de 
projets: 

1 .  Le  responsable  de  projet  intuitif  est  capable  de  gérer  un  projet  de  petite  envergure  ou 
simple  très  efficacement,  avec  une  petite  équipe.  Il  fait  confiance  à  son  propre  bon 
sens,  essentiellement  dû  à  une  bonne  pratique  de  la  gestion  de  projets.  Intuitivement,  il 
fait  participer  les  parties  intéressées,  recherche  des  solutions,  planifie,  alloue  le  travail 
et  vérifie  l'évolution.  Beaucoup  de  responsable  de  projets  improvisé  ou  autoproclamés 
entrent  dans  cette  catégorie. 

2.  Le  responsable  de  projet  méthodique  est  capable  de  gérer  des  projets  de  plus  grande 
envergure  et  plus  complexes,  qu'il  ne  peut  suivre  dans  leur  intégrité  uniquement  à 
l'aide  d'outils  simples  et  de  sa  mémoire.  Des  méthodes,  des  protocoles  et  des  pratiques 
formels  sont  mis  en  place  pour  assurer  que  le  projet  est  géré  efficacement. 

3.  Le  responsable  de  projet  critique  peut  gérer  des  projets  très  complexes  et  souvent 
difficiles.  Il  peut  appliquer  des  méthodes  de  façon  créative  afin  de  construire  une 
méthode  et  un  plan  de  projet  qui  soient  à  la  fois  souples  et  efficaces,  tout  en  restant 
fidèle  à  tous  les  principes  d'une  bonne  gestion  de  projets. 

Nous  pouvons  considérer  que  pour  ce  poste,  la  performance  résulte  de  la  combinaison  de 
quatre  facteurs: 

1 .  La  connaissance  comprend  l'apprentissage  d'un  ensemble  d'outils  et  de  techniques  liés 
exclusivement  à  la  gestion  de  projets. 

2.  Les  compétences  sont  l'application  de  ces  outils  et  techniques. 

3.  Les  comportements  correspondent  à  l'attitude  et  au  style  du  responsable  de  projet 
dans  ses  rapports  avec  les  membres  de  son  équipe,  le  sponsor,  le  conseil 
d'administration  et  le  client. 

4.  L'expérience  mesure  la  profondeur  avec  laquelle  les  connaissances,  les  compétences 
ou  les  comportements  ont  été  appliqués. 

Beaucoup  d'ouvrages  spécialisés  recommandent  nombre  de  critères  pour  choisir  un  bon 
responsable  de  projet  et  basé  essentiellement  sur  des  compétences  relationnelles  et  non 
techniques.  Je  tiens  à  préciser  cependant  que  la  technique  (science)  a  permis  à  toutes  les 
branches  de  la  vie  de  se  développer  de  manière  fulgurant  e  avec  rigueur  et  exactitude.  Or  la 
majorité  des  responsables  de  projet  au  début  de  21eme  siècle  (et  avant. . .)  ont  des  méthodes  de 
travail  qui  sont  équivalentes  aux  décisions  de  saignées  que  faisaient  les  médecins  il  y  a  plus 
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de  3  siècles  pour  résoudre  un  problème. . .  jusqu'à  ce  que  la  méthode  scientifique  ait  fait  place 
nette. 

Par  ailleurs  la  médiocrité  de  taux  de  réussite  des  projets  montre  bien  que  ce  n'est  pas  la  bonne 
solution.  Quand  le  domaine  de  la  gestion  de  projets  sera  vraiment  à  maturité,  les  techniques 
scientifiques  seront  mises  en  place  comme  cela  l'a  déjà  été  pour  la  gestion  financière  et  la 
gestion  de  la  qualité  dans  le  domaine  de  la  gestion  de  projets  de  pointe  aux  Etats-Unis  et  en 
Asie  il  y  a  plus  de  50  ans. . .  avec  des  responsables  niveau  Bac+7. 

Bon  ceci  dit,  ce  n'est  pas  parce  qu'un  individu  gère  les  hommes  de  façon  exceptionnelle  ou 
qu'il  est  un  expert  technique  talentueux  qu'il  l'envergure  en  termes  de  savoir,  d'expérience, 
d'habilité,  de  communication,  de  leadership  pour  diriger  un  projet.  Le  monde  de  l'entreprise  et 
des  administrations  est  majoritairement  rempli  de  gens  promus  au-delà  de  leur  niveau  de 
compétences  -  et  ce  n'est  pas  de  leur  faute! 

Remarque:  Un  responsable  d'un  niveau  modeste  dans  l'échelle  hiérarchique  se  doit  de 
maîtriser  mieux  que  ses  employés  tous  les  aspects  techniques  de  la  profession!  C'est  donc 
pour  lui  un  point  crucial  s'il  veut  se  faire  respecter.  D'autant  que  les  subalternes  n'ont  aucune 
peine  à  se  faire  une  idée  du  niveau  de  compétence  et  peuvent  dès  lors  adopter  un 
comportement  dominant  envers  celui-ci.  Du  coup,  ils  résistent  plus  à  l'influence  de  leur 
supérieur,  remettent  en  question  ses  ordres  et  critiquent  plus  ouvertement  ses  décisions. 

Ce  type  de  compétence  n'est  pas  autant  demandé  de  la  part  d'un  top  manager  (personne 
dirigeant  une  équipe  de  plusieurs  milliers  de  personnes).  On  attend  de  lui  de  fortes 
compétences  interpersonnelles,  c'est-à-dire  une  capacité  à  initier  et  maintenir  des  relations 
avec  les  autres,  de  faire  preuve  d'empathie  et  d'une  bonne  aptitude  à  communiquer. 

8.3.1  Le  principe  de  Peter 

Un  grand  classique  repris  tel  quel  de  Wikipédia18  car  permet  souvent  de  se  remettre  en 
questions  (ou  d'en  remettre  d'autres  en  question. . .): 

Le  Principe  de  Peter,  également  appelé  de  Laurence  J.  Peter  et  Raymond  Hull  (1969),  est  un 
principe  satirique  relatif  à  l'organisation  hiérarchique.  Selon  ce  principe: 

«  Tout  employé  tend  à  s'élever  à  son  niveau  d'incompétence.  » 


18  "Principe  de  Peter."  Wikipédia,  l'encyclopédie  libre.  28  fév  2011,  03:44  UTC.  3  mar  2011,  19:47 
http://fr.wikipedia.org/w/index.php?title=Principe  de  Peter&oldid=62730798. 


Ingénierie  de  Gestion  de  projets 


154/547 


Vincent  ISOZ 


LE  PRINCIPE  DE  MUENT  : 

Les  employés  les  plus  incompétents 
sont  systématiquement  promus  aux  postes 
où  ils  se  révèlent  le  moins  dangereux  : 
l’encadrement. 


Il  est  suivi  du  corollaire  de  Peter: 

«  Avec  le  temps,  tout  poste  sera  occupé  par  un  incompétent  incapable  d'en  assumer  la 

responsabilité.  » 

Les  principes  de  base  sont  les  suivants: 

•  un  employé  compétent  à  un  poste  donné  est  promu  à  un  niveau  hiérarchique  supérieur 

•  un  incompétent  à  un  poste  donné  n'est  pas  promu  à  un  niveau  supérieur 

1er  corollaire: 

•  un  employé  ne  restera  dans  aucun  des  postes  où  il  est  compétent  puisqu'il  sera  promu  à 
des  niveaux  hiérarchiques  supérieurs. 

•  par  suite  des  promotions,  l'employé  finira  (peut-être)  par  atteindre  un  poste  auquel  il 
sera  incompétent. 

•  par  son  incompétence  à  ce  poste,  l'employé  ne  recevra  plus  de  promotion,  il  restera 
donc  indéfiniment  à  un  poste  pour  lequel  il  est  incompétent. 

2ème  corollaires: 

•  à  long  terme,  tous  les  postes  finissent  par  être  occupés  par  des  employés  incompétents 
pour  leur  fonction. 

•  la  majorité  du  travail  est  effectuée  par  des  salariés  n'ayant  pas  encore  atteint  leur 
«  seuil  d'incompétence  ». 

De  plus,  si  nous  partons  des  principes  que  plus  un  poste  est  élevé  dans  la  hiérarchie, 

•  plus  il  demande  des  compétences  ; 
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•  plus  son  impact  est  grand  sur  le  fonctionnement  de  l'organisation, 

alors  nous  pouvons  constater  que  l'impact  de  l'incompétence  de  l'employé  aura  été  maximisé 
par  le  niveau  hiérarchique  du  poste  auquel  il  aura  été  promu.  Ces  dernières  hypothèses  ne  sont 
qu'une  interprétation  non  systématiquement  retenue  du  principe  de  Peter. 

Peter  remarque  que  la  compétence,  chez  les  employés  d'une  organisation,  se  répartirait 
(chiffres  qui  selon  mon  expérience  ne  doivent  pas  être  trop  éloignés  de  la  réalité): 

-  10  %  sont  super  incompétents 

-  20  %  sont  incompétents  (30%  cumulé  jusqu'ici) 

-  40  %  sont  modérément  compétents  (70%  cumulé  jusqu'ici) 

-  20  %  sont  compétents  (90%  cumulé  jusqu'ici) 

-  9%  super  compétents  (99%  cumulé  jusqu'ici) 

-  1%  sont  exceptionnels  (hauts  potentiels) 

Une  version  moderne  du  principe  de  Peter  serait  s'énoncerait  selon  certains:  «  Les  gens  les 
moins  compétents  sont  systématiquement  affectés  aux  postes  où  ils  risquent  de  causer  le 
moins  de  dégâts:  ceux  de  managers.  » 

Je  recommande  fortement  la  lecture  complète  de  l'article  sur  Wikipédia  qui  tient  bien  la  route! 


8.3.2  Sélectionner  un  bon  responsable  de  projet 

J'ai  eu  l'occasion  une  fois  de  suivre  une  micro-conférence  d'Adecco  en  Suisse  (avril  2010)  sur 
les  critères  de  base  de  sélection  d'un  responsable  de  projet.  Bien  que  l'exigence  soit  peu  élevée 
j'ai  trouvé  intéressant  de  faire  un  résumé  dans  le  présent  ouvrage  et  de  les  compléter  avec  des 
remarques  personnelles  (en  vert). 

Pour  résumer  de  manière  extrêmement  condensée  avant  d'aller  dans  les  détails:  On  demande  à 
un  responsable  de  projets  de  posséder  un  portefeuille  de  recettes  ou  outils  et  d'être  capable 
d'analyser  un  contexte,  d'isoler  des  causalités  essentielles  dans  un  univers  complexe,  de 
concevoir  des  scénarios.  Il  doit  faire  preuve  d'une  grande  curiosité  (ouverture  intellectuelle ) 
et  vivacité  d'esprit  et  être  doté  d'une  capacité  analytique  pointue  pour  émettre  des  jugements 
sûrs  (toute  subjectivité  est  exclue ).  Au  niveau  humain,  le  responsable  de  projet  doit  avoir  une 
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grande  maîtrise  de  soi,  une  empathie  et  un  sens  élevé  de  la  diplomatie  envers  ses  ressources 
et  supérieurs. 

Il  faut  également  considérer  deux  types  de  responsables  de  projets: 

1.  Les  consultants  externes  experts  qui  doivent  posséder  une  expérience  très  pointue  et 
dont  il  faut  passer  l'entreprise  au  crible  via  un  audit  ou  des  tests  de  connaissances  très 
difficiles.  Faire  une  erreur  dès  le  départ  peut  se  révéler  catastrophique. 

2.  Les  responsables  de  projets  internes.  Cela  à  l'avantage  d'être  moins  cher  mais  jaugez - 
les  aussi  sévèrement  que  des  consultants  externes. 


I£  y  ou  think 

it>s  exp®nsive 
to  hir®  » 

prof essional , 

«ait 

yOU  k*-re 

an  amateur. 


8.3.2. 1  Compétences 

Donc  selon  Adecco  (Suisse)  un  responsable  de  projet  devrait  satisfaire  de  manière  équilibrée 
aux  compétences  suivantes  (je  pense  -  et  j'espère...  -  que  dans  un  souci  de  simplification  par 
rapport  à  l'auditoire  ils  n'ont  pas  voulu  aller  trop  dans  les  détails): 

1.  Compétences  comportementales 

1.1.  Dynamique,  passionné,  entreprenant 

1.2.  Orienté  vers  les  résultats 

(quantifiables  avec  des  outils  statistiques  avancés) 

1.3.  Pouvant  travailler  indépendamment  et  respecter  les  délais 
(en  utilisant  des  techniques  avancées  de  gestion  du  temps) 

1.4.  Bon  sens  de  la  négociation  et  de  la  communication 

(doit  maîtriser  les  sujets  dont  il  parle  au  moins  aussi  bien  que  ses  interlocuteurs) 

1.5.  Créatif,  polyvalent  et  motivé  pour  trouver  constamment  de  nouvelles  solutions 

(des  solutions  correspondantes  aux  techniques  contemporaines  et  non  d'il  y  a  plus  de 
100  ans...) 
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1 .6.  Apte  à  planifier,  organiser,  programmer  et  coordonner  de  multiples  tâches  afin 
d'atteindre  les  objectifs  planifiés 

(avec  les  bons  outils:  c'est-à-dire  sans  tableau  ni  logiciel  de  traitement  de  texte  pour 
faire  cela...) 

1.7.  Prêt  à  prendre  des  risques  (calculés!),  capacité  de  prendre  des  décisions  (avec  les 
outils  d'aide  à  la  décision!) 

1.8.  Aptitude  à  développer  ses  propres  capacités  (faire  passer  un  test  de  raisonnement  et 
de  logique  à  tout  futur  responsable  de  projet. . .  !),  ainsi  que  celle  des  autres 

2.  Compétences  techniques 

2.1.  Gestion  des  fournisseurs  (connaître  les  techniques  d'optimisation  de 
l'approvisionnement,  les  contrôles  de  réception  et  de  l'optimisation  des  flux) 

2.2.  Connaissances  des  opérations  d'outsourcing  et  d'offshoring  (connaître  ou  être  expert 
dans  l'utilisation  des  standards  ISO  et  la  législation  utiles  à  ce  type  d'activité) 

2.3.  People  management,  capable  de  développer  et  de  guider  son  équipe  (capable  de  gérer 
des  ressources  avec  le  même  niveau  de  qualité  et  de  rigueur  qu'un  projet  lui-même) 

2.4.  Capable  d'influencer  (positivement  et  intelligemment)  une  équipe 

2.5.  Compétences  d'ingénierie  financière  et  d'ingénierie  statistique  de  base  (estimation 
probabiliste  des  échéances,  couverture  financière  des  risques) 

3.  Compétences  en  gestion  de  projets 

3.1.  Compréhension  de  méthodologies  de  gestion  de  projet  comme  PRINCE2  ,  Hermes, 
Agile... 

(avoir  étudié  de  manière  assez  fouillée  au  moins  5  méthodologies  de  gestion  de  projet 
reconnues  au  niveau  international) 

3.2.  Bonne  compréhension  des  échanges,  en  termes  de  temps  passé  sur  le  projet,  les  coûts, 
la  qualité,  et  le  résultat 

(être  capable  de  mettre  en  place  un  glossaire  et  des  techniques  analytiques 
automatisées  et  sophistiquées  de  réalisation  d'un  projet) 

3.3.  Capacité  à  créer  et  vérifier  différents  cas  concrets 

(capacité  à  déléguer  les  choix  et  estimations  à  ceux  qui  en  ont  les  compétences) 

3.4.  Bonne  gestion  de  projets 

(avoir  au  moins  une  maîtrise  universitaire  -  ou  connaissances  équivalentes  -  dans  le 
domaine  de  la  gestion  de  projets  ou  dans  un  domaine  directement  connexe  et  la 
maîtrise  des  outils  informatiques  ad  hoc). 

3.5.  Profondes  connaissances  de  la  gestion  des  risques  et  questions  liées  au  management 
(connaissances  statistiques  pointures  et  formation  de  niveau  universitaire  selon  les 
mêmes  critères  que  ceux  donnés  précédemment!) 

4.  Compétences  IT 
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4.1.  Bonnes  connaissances  des  méthodes  et  outils  IT 

(avoir  une  formation  continue  pointue  sur  chacun  des  outils  utilisés  et  avoir  passé  un 
test  de  niveau  universitaire  lors  de  l'embauche) 

4.2.  Compréhension  des  méthodes  de  test,  des  processus  et  des  outils 

(connaître  les  probabilités  conditionnelles,  l'AMDEC  quantitative,  ISO  5807:1985  et 
les  logiciels  d'accompagnement  aux  calculs) 

4.3.  Connaissances  des  technologies 

(savoir  quels  sont  les  bons  outils  par  rapport  à  des  besoins  clairement  identifiés) 

4.4.  Compréhension  de  l'analyse  business  et  du  processus  de  conception 
(avoir  une  formation  Six  Sigma  et  la  partie  DOE  qui  y  est  incluse) 

4.5.  Capacité  de  développer  des  S.L.A.  (Service  Level  Agreement) 

(maîtriser  les  points  précédents. . .) 

On  peut  conclure  de  la  liste  ci-dessus  que  le  responsable  de  projet  n'est  finalement  qu'un 
"faciliateur"  de  la  communication  transversale  dans  une  organisation  (ceci  dit  c'est  très  utile!). 

On  notera  que  le  PM2  considère  comme  les  compétences  du  responsable  de  projets: 


qui  est  assez  gravissime  et  inquiétant  car  finalement  on  attend  de  lui  aucun  compétence 
technique  (calculs  financiers,  modélisation  mathématique  des  planifications  et  des  risques, 
etc.).  C'est  assez  navrant  pour  une  structure  de  la  taille  de  la  comission  Européenne  qui 
normalement  devrait  utiliser  au  vu  de  certains  budgets  les  mêmes  méthodes  que  la  NASA. 
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8. 3. 2.2  L'interview 

Toujours  dans  la  cadre  de  la  recherche  du  responsable  de  projet,  la  prochaine  étape  est 
l'interview  (doit  durer  au  minimum  3  heures  pour  une  bonne  sélection!).  Adecco  propose  un 
modèle  relativement  bien  ficelé  qui  consiste  en  plusieurs  étapes  à  mettre  sous  forme  de 
tableau  avec  des  notes  et  des  pondérations  en  fonction  des  besoins19: 

Première  étape: 

1 .  Analyser  le  C V  en  détails  avant  l'interview 

2.  Demander  au  candidat  qu'elles  sont  selon  lui  les  compétences  d'un  responsable  de 
projet  (vérifier  si  réponse  conforme  au  PMBOK) 

3.  Valider  ses  compétences  en  posant  des  questions  techniques  pointues 

4.  Demander  au  candidat  de  décrire  ses  activités  au  travail,  ses  réalisations  et  formations 
dans  le  domaine 

5.  Comprendre  pour  quelle  raison  le  candidat  souhaite  quitter  son  poste  actuel  (vérifier 
en  même  temps  qu'il  respect  la  clause  de  confidentialité  de  son  ancien  employeur) 

6.  Demander  au  candidat  pour  il  estime  être  la  bonne  personne  pour  ce  poste? 

7.  Quelles  sont  les  innovations  managériales  que  le  candidat  a  apporté  à  son  précédent 
poste  et  qu'elles  ont  été  leurs  impacts? 

8.  Quelles  ont  été  selon  lui  ses  responsabilités  les  plus  importantes? 

9.  De  quelles  réussites  est-il  particulièrement  fier? 

10.  Demander  au  candidat  ses  objectifs  de  carrière 

Deuxième  étape: 

1.  Comment  le  candidat  prépare-t-il  un  projet  (vérifier  qu'il  se  base  sur  des  processus 
connus!) 

2.  Comment  le  candidat  gérerait-il  les  personnes  non-productives  ou  non  motivées? 

3.  Comment  le  candidat  gérerait-il  les  membres  d'équipe  qui  viennent  vous  voir  pour  des 
problèmes  personnels? 

4.  Comment  le  candidat  gérerait-il  la  situation  où  il  y  a  plusieurs  réponses  à  une 
problématique  proposées  par  l'équipe  de  projet. 

5.  Citer  un  exemple  d'une  situation  Win  Win  que  le  candidat  aurait  négocié. 

6.  Qu'est-ce  que  le  candidat  aurait  appris  d'éventuels  échecs  dans  le  cadre  de  projets? 

7.  Est-ce  que  le  candidat  peut  indiquer  5  signes  annonceurs  de  l'échec  probable  d'un 
projet? 

8.  Quelle  est  la  décision  la  plus  difficile  que  le  candidat  ait  eu  à  prendre  (toujours  dans  le 
cadre  de  projets) 

9.  Quelle  est  la  plus  belle  réussite  et  le  plus  grand  fiasco  du  candidat? 

Troisième  étape: 

1 .  Réaliser  un  jeu  de  rôle 

2.  Présenter  une  étude  de  cas  où  le  projet  doit  être  rapidement  évalué  en  termes  de  coûts 
et  temps 


19  J'ai  complété,  corrigé  (car  il  y  avait  des  aberrations  et  fautes  d'orthographe. . .)  et  réordonné  un  peu  à  ma 
manière  cependant. . .  car  les  RH  souvent  évitent  tout  ce  qui  est  technique  dans  un  entretien  car  ils  ne  maîtrisent 
pas  les  sujets  et  posent  parfois  des  questions  dont  les  pièges  sont  évidents  ou  anticipés  dans  le  CV  par  les  hauts 
potentiels  et  n'apportent  donc  aucune  plus-value. 
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3.  Présenter  une  étude  de  cas  où  le  projet  est  en  train  d'échouer  et  évaluer  le  candidat  par 
rapport  à  son  approche  à  la  résolution  de  cette  problématique 

4.  Evaluer  le  candidat  sur  ses  compétences,  sa  stratégie  de  planification  et  son 
implication. 

5.  Evaluer  le  candidat  sur  ses  techniques  de  communications  orales  et  écrites 

Ensuite,  dans  le  cadre  du  processus  de  recrutement  interne  à  l'entreprise  j'insiste  sur  une  chose 
évidente. . .  que  les  ressources  intervenant  sur  les  projets  devront  se  souvenir  aussi  par 
moment...: 


On  a  que  ce  dont  pour  quoi  on  est  prêt  à  payer... 

Il  ne  faut  effectivement  pas  attendre  de  miracles  d'un  responsable  de  projet  dont  le  niveau  de 
compétence  équivaut  selon  l'équation  des  salaires  à  environ  (selon  tarif  Suisse  en  2011)  un 
salaire  brut  de  ÎO'OOO  CHF/mois  (sur  12  mois).  Effectivement,  un  salaire  d'un  haut  potentiel 
extrêmement  compétent  aura  lui  un  salaire  se  situant  entre  30'000  et  150'000  CHF/mois  pour 
travailler  sur  des  projets  de  plusieurs  dizaines  de  millions  de  CHF!  !  ! 

De  plus  il  faut  savoir  que  dans  la  réalité  les  départements  de  ressources  humaines  font  presque 
tous  uniquement  des  tests  de  la  personnalité  pour  les  responsables  de  projets  et  top  managers 
qu'ils  souhaitent  engager  et  non  des  tests  de  compétences  techniques  d'ingénierie  de  la  gestion 
de  projets.  Donc  très  souvent  on  se  retrouve  avec  des  cadres  qui  ont  un  très  bon  profil 
relationnel  mais  qui  techniquement  ne  comprennent  pas  grand-chose  au  contenu  de  leurs 
projets  et  qui  ne  connaissent  souvent  rien  à  1'  de  la  gestion  de  projets. 

8.3.3  Profil  d’entreprise  type 

Le  responsable  de  projet  travaille  très  souvent  (majoritairement)  dans  des  entreprises  où  la 
réalité  est  niée,  l'imaginaire  hypotrophié  et  la  symbolique  hypertrophié. 

•  Négation  de  la  réalité:  Si  l'entreprise  a  des  problèmes,  subit  des  dysfonctionnements, 
cela  peut  signifier  qu'elle  a  vécu  et  vit  peut-être  toujours  dans  la  négation  de  la  réalité, 
qu'elle  n'a  pas  mis  en  place  le  minimum  de  veille  nécessaire,  qu'elle  n'accepte  pas  de 
se  voir  comme  elle  est.  Elle  n'est  pas  capable  de  regarder  la  réalité  en  face. 

•  Hypotrophie  de  l'imaginaire:  Les  maîtres  mots  des  entreprises  sont  souvent 
réduction  des  coûts,  plan  social,  rentabilité  non  réfléchie  et  autres  classiques.  De  fait,  il 
est  difficile  de  susciter  l'imaginaire.  L'imagination  et  la  créativité  sont  alors  proscrites 
en  dehors  des  départements  de  R&D  et  des  groupements  de  hauts  potentiels. 

•  Hypertrophie  du  symbolique:  Des  dirigeants  d'entreprise  ont  parfois  hypertrophié  le 
symbolique  en  ayant  nié  la  réalité  et  n'ayant  pas  pu  susciter  l'imaginaire  et  permettre  le 
développement  de  l'imagination  de  de  la  créativité  chez  les  salariés. 

Ces  dirigeants  accordent  une  importance  démesurée  aux  symboles  comme  le  mobilier 
design  dans  leur  bureau,  une  voiture  haut  de  gamme,  une  place  de  parking  réservée. . . 
Ces  symboles  sont  représentatifs  de  leur  fonction  et  renforcent  leur  puissance  et  leur 
pouvoir  face  aux  autres. 
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Le  responsable  de  projet  doit  alors  souvent  trouver  une  équilibre  entre  ces  trois  principales 
caractéristiques: 


Des  propositions  peuvent  être  apportées  par  le  responsable  de  projet  sur  chaque  point: 

•  Sur  la  réalité:  Aider  l'entreprise  à  regarder  la  réalité  en  face.  Lui  permettre  d'accepter 
les  indicateurs  de  performance,  de  bien-être,  les  outils  de  comparaison,  d’admettre  les 
veilles  technologiques  et  concurrentielles  comme  une  opportunité  et  non  plus  comme 
une  menace.  L'opportunité  est  d'adapter  sa  stratégie,  sa  structure,  son  organisation  en 
trouvant  un  équilibre  entre  les  réalités  du  marché  et  les  attentes  de  ses  employés. 

•  Sur  l'imaginaire:  Les  recommandations  à  ce  surjet  peuvent  être  appliquées  comme  de 
vrais  projets  qui  non  seulement  peut  faire  mieux  vivre  l'entreprise  pas  son  chiffre 
d'affaires  et  sa  marge,  mais  aussi  permet  le  développement  des  personnels,  privilégie 
la  prise  d'initiatives,  de  risque,  potentialise  leurs  compétences  et  met  aussi  les 
méthodes  de  gestion  de  projet  à  l'épreuve  en  tant  que  laboratoire  de  test. 

•  Sur  la  symbolique:  Les  répercussions  de  certaines  symboliques  sur  l'ensemble  des 
employés  doit  être  adapté  afin  d'éviter  les  ruptures  sociales  flagrantes  entre  les 
différents  niveaux  hiérarchiques.  Montrer  que  certains  choix  actuel  engendrent  des 
coûts  indirects  est  une  voie  possible. 

L'équilibre  est  bien  évidemment  difficile  à  réaliser  dans  la  majorité  des  cas  que  le  responsable 
de  projets  soit  un  expert  ou  non. 

8.4  Formation  de  l’équipe  de  projet 

Le  travail  d'équipe  est  essentiel.  En  cas  d'erreur,  ça  permet  d'accuser  quelqu'un  d'autre... 

Remarque:  Je  recommande  très  fortement  à  toute  personne  intéressée  à  changer  la  mentalité 
qui  consiste  à  faire  en  sorte  que  les  ressources  courent  après  le  temps  au  détriment  du  bien- 
être  du  client  et  de  la  qualité  du  produit  à  se  renseigner  sur  le  "slow  management". 

Un  aspect  important  du  travail  du  coordinateur  du  projet  est  de  gérer  les  ressources  humaines 
affectées  à  un  projet  et  de  contrôler  les  changements  afin  de  minimiser  tout  impact  nuisible  à 
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l'accomplissement  des  objectifs  du  projet.  Certains  changements  sont  insignifiants  alors  que 
d'autres  sont  d'importance  capitale  dans  la  vie  du  projet. 

Dans  certaines  situations  et  dans  le  cadre  de  certains  projets,  il  est  possible  et  parfois  même 
conseillé  de  regrouper  l'organisation  du  projet  sur  un  site  unique  de  sorte  que  les  acteurs  du 
projet  soient  proches  les  uns  des  autres.  Cette  mesure  améliore  le  travail  en  équipe  et  la 
communication.  Il  se  peut  en  revanche  que  certaines  unités  de  l'organisation  du  projet  soient 
très  éloignées  géographiquement,  voire  se  trouvent  sur  des  continents  très  différents,  ce  qui 
constitue  un  défi  supplémentaire  pour  la  gestion  du  projet. 
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La  performance  d'une  organisation  de  projet  dépend  de  ses  acteurs.  La  compétence  des 
personnes  choisies  doit  être  vérifiée  et  leur  disponibilité  convenue  avec  leur  hiérarchie.  Dans 
l'idéal,  le  responsable  de  projet  et  les  responsables  hiérarchiques  de  l'unité  d'organisation  qui 
fournit  les  ressources  humaines  examinent  ensemble  la  qualification  de  chaque  personne 
retenue  pour  exercer  une  fonction  donnée  dans  le  cadre  du  projet.  Cet  examen  commun  porte 
sur  le  savoir,  les  capacités  et  l'expérience  de  la  personne.  Le  responsable  de  projet  prend 
également  en  compte  la  personnalité  de  l'individu  et  son  potentiel  d'intégration  dans  l'équipe. 

Il  convient  que  la  définition  des  rôles  et  responsabilités  en  matière  de  gestion  de  projets  (et 
tous  les  spécialisations  et  métier  de  l'écosystème  de  la  gestion)  fasse  partie  des  procédures 
d'accueil  des  nouveaux  arrivants  (newcomer)  à  un  poste  ou  une  fonction.  L'organisme  doit 
s'assurer  que  l'organisme  s'assure  que  les  personnes  responsables  sont  en  mesure  de  remplir  ce 
rôle  en  leur  fournissant  l'autorité,  le  temps,  la  formation,  les  ressources  et  les  compétences 
nécessaires  pour  assumer  leurs  responsabilités. 
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8.4.1  SCRUM 

En  2001,  17  représentants  des  méthodes  légères  alternatives  aux  processus  lourds 
traditionnels  se  sont  réunis  pour  trouver  les  points  communs  à  leurs  méthodes.  De  cette 
réunion  de  quelques  jours  est  né  le  Manifeste  Agile:  un  texte  bref  énonçant  des  grands 
concepts,  simples,  mais  qui  proposent  une  nouvelle  façon  de  penser  un  projet.  C'est  une 
méthode  de  gestion  orientée  quasiment  que  vers  l'humain  (relationnel)  et  fait  abstraction  des 
processus,  méthodes,  normes  et  mesures  (dans  l'optique  que  trop  de  méthodes  tu  la 
méthode...).  C'est  pour  cette  raison  que  nous  l'incluons  brièvement  dans  ce  chapitre  sur 
l'équipe  de  projet.  Par  ailleurs  je  préconise  fortement  cette  méthode  pour  les  entités  n'ayant 
pas  de  P.M.O.  (Project  Management  Office)  ni  de  structure  de  gestion  de  projets  (pas  de 
responsables  de  projets  payés  à  plein  temps  pour  faire  que  de  la  gestion  de  projets!)  et  ne 
travaillant  pas  dans  l'ingénierie  de  haut  niveau. 

Le  manifeste  agile  résume  sa  philosophie  en  quatre  oppositions  entre  les  concepts 
traditionnels  (méthode  la-rache20. . .)  et  les  concepts  proposés. 

Individus  et  interactions  contre  processus  et  outils 

Ce  sont  les  individus  qui  font  la  valeur  du  travail  accompli,  ce  sont  donc  eux  que  l'on  doit 
privilégier.  Sans  l'artisan,  les  meilleurs  outils  ne  servent  à  rien.  Les  processus  qui  définissent 
ce  que  doit  faire  chaque  personne  brident  le  potentiel  caché  derrière  chacun:  faire  interagir  les 
gens  au  maximum  est  bien  plus  fructueux  et  permet  d'améliorer  grandement  l'efficacité  et  la 
qualité  du  travail  fourni,  en  rassemblant  des  visions  différentes  d'un  même  problème. 


20  Jeu  de  mot  avec  "à  l'arrache" 
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Ceci  dit,  en  tout  objectivité  l'approche  est  limitée  dès  qu'il  s'agit  de  projets  à  plusieurs 
centaines  de  millions  de  francs  dans  des  domaines  comme  le  nucléaire,  l'électrotechnique, 
l'aéronautique  (bref  tout  domaine  considéré  comme  "sensible"). 


Logiciel  qui  fonctionne  contre  documentation  exhaustive 

Les  processus  lourds  génèrent  une  documentation  qui  se  veut  exhaustive  avec  tous  ses 
inconvénients:  ambiguïté  du  langage,  coût  de  la  rédaction,  coût  du  maintien  en  accord  avec  la 
réalité,  etc.  Ces  documents  ne  sont  qu'une  illusion  d'avancement  du  projet.  Même  une 
conception  technique  initiale  peut  être  complètement  remise  en  cause  en  phase  de  codage  (ou 
après):  comment  peut-on  alors  déterminer  l'avancement  du  projet?  Une  régression? 

Dans  les  méthodes  Agiles,  un  seul  critère  permet  de  mesurer  l'avancement  d'un  projet:  le 
logiciel  qui  fonctionne.  La  documentation  n'est  qu'un  support  concret  qui  aide  à  produire  le 
logiciel. 

Collaboration  du  client  contre  négociation  de  contrat 

Dans  tout  projet,  le  but  premier  est  de  gagner  de  l'argent,  autant  pour  le  client  (rentabilisation) 
que  pour  le  fournisseur  (prestation).  Si  la  négociation  protège  plus  ou  moins  des  risques 
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financiers,  elle  peut  provoquer  l'échec  des  projets  (délais  non  respectés,  budgets  insuffisants) 
et  engendrer  d’interminables  procès  où  tout  le  monde  y  perd  au  bout  du  compte  (le  client  n'a 
pas  son  logiciel  et  le  fournisseur  ferme  boutique). 

Il  faut  sortir  de  la  guerre  client/fournisseur  et  penser  en  équipe  qui  veut  atteindre  un  but 
commun:  réussir  le  projet  dans  le  cadre  dans  une  optique  Win-Win  en  oubliant  pas  de  définir 
la  négociation  sur  les  critères  minimaux  triviaux  OCEAN  (Objectif,  Contexte,  Enjeux, 
Asymétrie  de  pouvoir,  Négociateurs). 

Réponse  au  changement  contre  suivi  d'un  plan  prédéfini 

Un  plan  prédéfini  a  tendance  à  nous  rendre  autistes  aux  événements  qui  surviennent  pendant 
le  projet.  Il  est  en  plus  à  l'origine  des  conflits  client/foumisseur  classiques  sur  les  délais  de 
livraison.  Pour  le  client,  pouvoir  adapter  les  besoins  en  cours  de  projet  est  un  atout 
concurrentiel:  il  est  réactif  aux  fluctuations  des  marchés  et  s'assure  en  plus  que  le  logiciel 
développé  répond  parfaitement  à  ses  véritables  besoins. 


Les  méthodes  Agiles  sont  conçues  pour  s'adapter  au  changement,  en  assurant  un  plan 
macroscopique  précis  et  adaptatif. 


WEHÊ  GOING  Tû 
TR  Y  SOMETHING 
CAL L ED  AGILE 
PROGRAMMING. 


THAT  MEANS  NO  MORE 
PLANNING  AND  NO  MORE 
DOCUMENTATION.  JUST 
ST  ART  LJRITÏNG  CODE 
AND  COMPLAINÎNG. 


% 

□ 
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I  M  GLAD 
IT  HAS  A 
NAME. 


THAT 
UJAS  YOUR 
TRAINING. 
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8.4.2  Equipe  de  projet 


Tm  sorry,  you're  overqualified.  Corne  back  when 
you've  forgotten  some  things." 


Une  équipe  est  un  groupe  de  personnes  qui  travaille  ensemble  pour  accomplir  un  objectif 
commun.  Chaque  équipe  évolue  en  passant  par  plusieurs  étapes  de  développement.  Les 
coordinateurs  du  projet  doivent  prendre  conscience  des  étapes  à  rencontrer  pour  développer 
une  équipe  effective  et  cohésive: 


1.  Formation  du  groupe 

N 

y 

/ 

2.  Mise  en  conflit  du  groupe 

N 

J 

3.  Dérivation  des  normes 

y 

4.  Performance  du  groupe 

V _ 

j 

) 


Figure  12  Procédure  de  mise  en  place  de  groupes  de  travail 


Expliquons  ces  étapes  (Formation,  Confrontation,  Normalisation,  Production:  FCNP)  d’une 
façon  détaillée: 

8.4.2. 1  Forming 

Formation  du  groupe  (Forming):  Pendant  l’étape  de  formation  de  groupe  (Forming),  le 
coordinateur  de  projet  doit  fournir  des  directions.  En  donnant  des  directions  à  l’équipe  du 
projet,  le  coordinateur  de  projet  doit  clairement  communiquer  les  objectifs  du  projet  et  les 
bienfaits  qu’ils  amèneront.  Le  coordinateur  de  projet  doit  aussi  créer  une  vision  de  réussite  à 
l’égard  du  projet.  Les  contraintes  concernant  l’étendue  du  travail,  le  niveau  de  qualité,  le 
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budget  et  l'horaire.  Le  coordinateur  de  projet  doit  aussi  discuter  du  processus  de  formation 
d'équipe;  les  raisons  expliquant  la  sélection  des  membres  de  l'équipe,  leurs  niveaux  de 
compétences,  leurs  domaines  de  connaissances,  et  le  rôle  de  chaque  personne  dans 
l'accomplissement  des  objectifs  (selon  ISO  9001,  les  ressources  humaines  doivent  avoir 
documenté  les  formations  initiales,  formations  continues,  savoir-faire  et  expérience  des 
employés!).  Établir  des  structures  est  une  autre  tâche  que  doit  exécuter  le  coordinateur  de 
projet  pendant  cette  phase.  Ceci  inclus  la  définition  des  procédures  initiales  pour  le 
fonctionnement  de  l'équipe  et  le  traitement  des  réseaux  de  communication  d'approbation  et  de 
paperasse  (workflow,  business  process).  Ces  procédés  et  procédures  peuvent  être  améliorés 
par  les  membres  de  l'équipe  à  mesure  que  le  travail  avance.  Afin  de  réduire  le  stress,  le 
coordinateur  de  projet  devrait  discuter  de  son  style  de  gestion  et  de  ses  attentes  en  ce  qui 
concerne  le  travail  et  le  comportement  des  membres  de  l'équipe.  Il  importe  aussi  de  faire 
travailler  l'équipe  sur  des  tâches  initiales.  C'est  ici  que  le  coordinateur  du  de  projet  parvient  à 
faire  participer  l'équipe  au  développement  des  plans  du  projet  avec  un  certain  niveau  de 
délégation. 


La  figure  ci-dessous  montre  la  progression  du  degré  de  délégation  (où  certaines  personnes 
considèrent  parfois  que  le  degré  de  délégation  peut  être  inversement  proportionnel  à  la 
criticité  des  tâches): 
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Degré  de  délégation  minimal 


Faites  une  investigation  sur  le  problème.  Donnes  moi 
tous  les  Faits,  et  je  vais  décider  qui  effectuera  le  travail 


Faites  une  investigation  sur  le  problème.  Donnes  moi  les 
solutions  possibles  et  recommandes  en  une.  J'évaluerai  et 
déciderai 


Faites  une  investigation  sur  le  problème.  Faites  moi 
connaître  les  actions  que  vous  prendries.  Commences  à 
moins  que  je  n'en  dise  le  contraire 


Faites  une  investigation  sur  le  problème  et  prenes  les 
décisions  pour  le  résoudre.  Faites  moi  un  compte  rendu 
de  ce  que  vous  aves  Fait. 


Faites  une  investigation  sur  le  problème  et  prenes  les 
décisions  pour  le  résoudre.  Vous  jugeres  si  vous  aves 
besoin  de  m'en  parler. 


Degré  de  délégation  maximal 


Figure  13  Degrés  de  délégation 

Ainsi,  les  responsables  de  la  décision  sont  clairement  désignés:  la  personne  qui  le  veut,  celle 
qui  le  fait  et  celle  qui  la  "paie".  De  plus  cette  technique  est  facile  à  définir  dans  une  liste  ou 
une  base  de  données  informatique. 

Insistons  sur  le  fait  que  définir  les  délégations  permet  d'éviter:  à  ce  que  personne  ne  prenne  de 
décision,  les  conflits  lors  de  prises  de  décision,  que  les  décisions  ne  soient  pas  acceptées  par 
les  bonnes  personnes  et  que  personne  ne  soit  consulté. 

Remarque:  J'aime  bien  la  citation  de  Stanislav  Lee  qui  s'applique  bien  dans  les  organisations 
n'ayant  pas  de  DD:  "Dans  une  avalanche,  aucun  flocon  de  neige  ne  se  sent  responsable".  À 
noter  aussi  que  dans  certains  pays  comme  au  Japon  il  est  dans  la  nature  des  gens 
(mentalité/éduction)  d'exécuter  sans  réfléchir  en  respectant  les  procédures  au  pied  de  la  lettre 
même  si  parfois  l'action  est  absurde.  Donc  il  faut  prendre  garde  bien  évidemment  aux  pays 
avec  lesquels  nous  travaillons  ! 

On  peut  aussi  résumer  les  DD  de  la  manière  suivante  (ce  fichier  fait  partie  des  modèles  qui 
vous  seront  fournis  pendant  la  formation): 
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PM:  Chef  de  projet 
PL:  Project  Leader 


Tableau  simple  de  résumé  des  groupes  et  de  leur  fonction 


PS 

BA 

RE 


Project  Sponsor 
Business  Analyst 
Ressource 


Objets 

Projet  XY 

Phase  ou  Tâche  XY.1 

Document  XY 

Niveau  de  délégation 

PM 

PL 

PS 

RE 

BA 

PM 

PL 

PS 

RE 

BA 

PM 

PL 

PS 

RE 

BA 

DI 

D2 

D3 

D4 

D5 

D6 

0 

0 

Membres: 

0 

0 

Membres: 

0 

0 

Membres: 

0 

0 

0 

Membres: 

0 

Membres: 

0 

0 

0 

Membres: 

Bill  Gates 

Vincent  Isoz 

0 

0 

0 

0 

0 

0 

Sur  les  gros  et  longs  projets  une  technique  supplémentaire  et  sympathique  est  de  faire  des  t- 
shirts  ou  bandoulières  de  couleurs  pour  reconnaître  les  différents  membres  des  groupes  du 
projet. 

8. 4.2.2  Storming 

Mise  en  conflit  du  groupe  (Storming):  La  deuxième  étape  du  développement  de  l'équipe  se 
nomme  Mise  en  conflit  du  groupe.  Elle  est  généralement  difficile  pour  tous  les  membres, 
mais  il  faut  absolument  passer  à  travers.  Il  est  impossible  d'éviter  cette  étape  de  formation. 

Les  membres  commencent  à  exercer  leurs  connaissances  en  accomplissant  les  tâches  qui  leurs 
ont  été  désignées.  C'est  à  ce  moment  que  les  attentes  et  la  réalité  se  croisent  dans  le  meilleur 
des  cas.  Évidemment  cela  produit  des  sentiments  de  tensions  et  des  conflits.  Lorsque  les 
membres  de  l'équipe  commencent  à  performer  leurs  rôles,  ils  résistent  à  l'autorité  du 
coordinateur  du  projet  et  les  règles  qui  ont  étés  mises  en  place.  Pendant  l'étape  de  mise  en 
conflit,  il  y  a  beaucoup  de  frustration,  d'hostilité  et  de  tension  donc  c'est  important  de  former 
des  méthodes  pour  résoudre  les  conflits.  Le  coordinateur  du  projet  doit  diriger  mais  moins 
qu'en  l'étape  de  formation.  Il  est  important  de  donner  des  clarifications  sur  les  tâches  pour  les 
membres  de  l'équipe  mais  en  même  temps,  leur  donner  des  opportunités  de  partager  le 
pouvoir  à  faire  les  décisions. 

Attention  cependant  à  la  dynamique  de  groupe,  comme  la  supposition  silencieuse,  par 
exemple.  On  a  souvent  tendance  à  s'imaginer  que  les  autres  pensent  comme  soi,  qu'ils 
disposent  des  mêmes  informations,  et  que,  s'ils  ne  s'expriment  pas,  c'est  que  l'on  a  tort  de 
s'inquiéter.  En  plus,  la  présence  d'un  leader  lors  du  storming  favorise  la  prise  de  risque 
inconsciente  car  les  discussions  sont  souvent  moins  vives  et  profondes  -  si  ce  n'est  totalement 
absente  -  que  lors  de  l'absence  d'un  leader.  Donc  le  fait  que  la  majorité  se  tait  pèse 
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considérablement  dans  les  mauvaises  décisions.  Des  études  auraient  par  ailleurs  montré  que 
des  groupes  menés  par  un  leader  ont  un  tendance  significative  à  prendre  des  risques  non 
évalués  et  que  plus  les  groupes  sont  grands,  plus  les  décisions  prises  sont  risquées,  parce  que 
la  traille  du  groupe  inhibe  la  parole. 

Il  paraît  que  l'armée  française  s'est  rendu  compte  qu'en  supprimant  les  protocoles 
hiérarchiques  dans  certaines  situations  précises,  on  parvenait  à  des  décisions  plus  réfléchies 
puisque  mises  à  l'épreuve  de  la  critique  démocratique  (finalement  ce  n'est  le  résultat  de  la 
théorie  des  Jeux  qui  date  d'il  y  a  presque  un  siècle...). 

8.4.23  Norming 

Dérivation  des  normes  (Norming):  Après  avoir  traversé  l'étape  de  Mise  en  conflit  du 
groupe,  l'équipe  poursuit  son  chemin  pour  se  rendre  à  l'étape  de  Dérivation  des  normes.  Les 
conflits  interpersonnels  devraient  pour  la  plupart  être  résolus.  En  général,  le  niveau  de  conflits 
devrait  être  inférieur  à  ce  qu'il  était  dans  l'étape  de  Mise  en  conflit  du  groupe  car  les  attentes 
personnelles  s'alignent  avec  la  réalité  de  la  situation.  Le  contrôle  et  les  décisions  sont 
transférés  du  coordinateur  de  projet  à  l'équipe.  La  cohésion  commence  alors  à  se  développer. 
Les  contributions  pour  accomplir  l'objectif  du  projet  sont  grandement  appréciées  de  chaque 
membre  de  l'équipe.  Les  informations,  idées,  et  sentiments  sont  mieux  partagés  ce  qui 
augmente  la  coopération.  Pendant  l'étape  Dérivation  de  normes  le  coordinateur  de  projet 
réduit  son  rôle  de  directeur  et  adopte  un  rôle  de  soutien.  La  performance  de  travail  s'active  et 
la  productivité  augmente. 

8. 4.2.4  Performing 

Performance  du  groupe  (Performing):  A  cette  étape,  dans  un  cadre  théorique  idéal,  l'équipe 
est  dévouée  et  devient  impatiente  à  atteindre  l'objectif  du  projet.  Le  niveau  de  performance  de 
travail  est  élevé  au  cours  de  cette  étape,  ainsi  que  la  confiance.  Il  y  a  un  grand  degré 
d'interdépendance,  les  membres  collaborent  fréquemment  et  veulent  s'entraider.  L'équipe 
possède  beaucoup  de  pouvoir.  Le  sentiment  de  satisfaction  grandit  au  fur  et  à  mesure  qu'il  y  a 
du  progrès  et  qu'il  est  reconnu.  Pendant  l'étape  «  performing  »,  le  coordinateur  de  projet 
délègue  entièrement  les  responsabilités  et  l'autorité.  Il  peut  ainsi  se  concentrer  sur  la 
performance  du  projet,  son  plan  et  sa  portée.  Son  rôle  est  de  faciliter  et  supporter  le 
développement  et  implanter  les  actions  correctives  si  le  progrès  actuel  prend  du  retard. 

Remarques : 

Rl.  Il  faut  parfois  également  planifier  la  réintégration  d'une  personne  ayant  participé  à  un 
projet.  Effectivement,  il  peut  être  difficile  pour  certaines  personnes  de  revenir  à  leur  poste  ou 
cahier  des  charges  routinier! 

R2.  Dans  le  cas  de  la  méthode  agile  (scrum)  l'équipe  ne  comporte  pas  de  rôles  prédéfinis,  elle 
est  autogérée.  Il  n'y  a  pas  non  plus  de  notion  de  hiérarchie  interne:  toutes  les  décisions  sont 
prises  ensemble  et  personne  ne  donne  d'ordre  à  l'équipe  sur  sa  façon  de  procéder. 
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8.4.3  Hiérarchie/Organisation 

L'organisation  managériale  la  plus  courante  est  appelée  "organisation  fonctionnelle":  elle  est 
basée  sur  une  hiérarchie  par  spécialisation/métier  et  non  pas  par  responsabilité. 

L'organisation  fonctionnelle  est  l'héritage  du  management  scientifique  de  F.  Taylor  et  H.  Ford 
où  les  individus  étaient  placés  dans  des  domaines  où  ils  excellaient  pour  être  plus  rapide,  ne 
pas  réinventer  la  roue,  être  innovants  ou  créatifs.  Le  côté  négatif  de  cette  méthode  est  que  les 
employés  sont  rangés  dans  des  cases  et  si  il  n'y  a  pas  un  bon  suivi  de  l'évolution  de  carrière,  le 
travail  peut  assez  vite  devenir  répétitif  et  ennuyeux  (souvent  déjà  à  partir  de  4  à  5  ans  à  un 
même  poste). 

Certaines  personnes  ayant  remarqué  que  ce  type  d'organisation  mettait  en  évidence  les 
incompétents  trop  facilement  ont  proposé  une  alternative  appelée  "organisation  matricielle" 
qu'ils  justifient  comme  plus  adaptée  aux  commerce  moderne  où  la  flexibilité  est  de  mise. 

En  réalité,  les  scientifiques  (les  "vrais"!)  remarquant  alors  que  les  entreprises  actuelles  sont 
alors  en  grande  majorité  remplies  d'employés  principalement  incompétents  et  ignorants  aux 
postes  auxquels  ils  se  trouvent  et  ces  mêmes  employés  perdent  10  à  15  ans  à  recréer  la  roue 
(sans  se  rendre  compte  puisqu'ils  se  complaisent  dans  l'ignorance)  de  ce  qu'un  spécialiste 
aurait  déjà  appris  en  apprentissage,  en  école  d'ingénieurs  ou  de  commerce  ou  à  l'université. 


À  UN  ENTRETIEN  ^EMBAUCHE  \ 


Comme  je  le  dis  toujours:  est-ce  qu'il  vaut  mieux  un  employé  qui  sait  un  peu  tout  faire,  très 
lentement  et  mal  ou  une  employé  qui  peut  faire  qu'une  ou  deux  choses  mais  rapidement  et  très 
bien? 
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L'état  actuel  des  organisations  se  comprend  lorsque  l'on  est  en  contact  direct  avec  les  cadres 
dirigeants  des  ressources  humaines  ou  que  l'on  voit  le  niveau  de  rigueur  de  rédaction  des 
offres  d'emplois  (et  ce  même  des  multinationales  renommées...  du  moins  en  dehors  du  cercle 
des  consultants  indépendants). 


Business 

Goveming 

Layer 


Steering 

Layer 


Directing 

Layer 


Managing 

Layer 


Performing 

Layer 


Figure  14  Organisation  selon  le  PM" 


8.4.4  Profils 


Le  simple  rassemblement  d'individus  (forming)  n'est  pas  suffisant  pour  créer  une  véritable 
équipe,  même  si  on  leur  demande  leur  accord  (storming)  pour  travailler  ensemble. 


La  performance  d'une  équipe  dépend  de  l'équilibre  des  rôles  tenus  par  chacun  de  ses 


membres.  En  effet,  c'est  dans  la  diversité  des  approches  qu'elle  est  capable  de  fournir  que 
réside  la  véritable  force  d'une  équipe. 

En  identifiant  les  rôles  endossés  par  chacun,  on  peut  augmenter  l'efficacité  de  l'équipe  en 
jouant,  à  bon  escient,  sur  sa  composition  ou  sur  son  fonctionnement  interne. 

Les  études  menées  à  Cambridge  par  Meredith  Belbin  pendant  plus  de  20  ans  ont  montré  qu'il 
existe  un  nombre  limité  de  rôles  en  équipe.  Chaque  rôle  se  structure  sur  des  constantes  de 
comportement  mises  en  œuvre  dans  le  cadre  professionnel  par  des  types  de  personnalité 
parfois  tout  à  fait  différents. 

Les  rôles  selon  ce  modèle  sont  construits  sur  axes  et  représentés  parfois  sous  la  forme  d'une 
molécule: 
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Rôles  de  réflexion 


PRISEUR  -  Modéré,  stratégique.  Il  fait  preuve  de  discernement  et  envisage 
toutes  les  options.  Evalue  avec  précision  et  de  manière  objective  si  les  idées 
sont  réalistes  et  bénéfiques. 


CONCEPTEUR  -  Créatif,  imaginatif,  peu  orthodoxe  et  surtout 
anticonformiste,  il  propose  de  nouvelles  idées  et  des  solutions  créatives.  Il 
résout  les  problèmes  complexes. 


EXPERT  -  Déterminé,  autonome,  concentré  vers  un  seul  objectif.  Il 
possède  une  source  de  connaissances  et  de  compétences  techniques  peu 
communes  et  utiles  à  l'équipe. 


Rôles  d'action 

ORGANISATEUR  -  Discipliné,  fiable,  ordonné,  méthodique  et  efficace.  Il 
transforme  les  idées  en  actions  concrètes  et  pratiques  que  les  membres  de 
l'équipe  pourront  réaliser. 

PROPULSEUR  -  Dynamique  et  fonceur,  il  travaille  bien  sous  pression.  Il 
a  le  courage  et  la  capacité  de  surmonter  les  obstacles.  Il  pousse  les  autres  à 
l'action  et  aide  l'équipe  à  recentrer  son  travail. 
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PERFECTIONNEUR  -  Il  s'assure  que  le  travail  est  bien  fini. 
Consciencieux,  à  la  recherche  des  erreurs  et  omissions.  Il  a  le  souci  de  la 
perfection.  Il  fait  en  sorte  que  le  programme  et  les  délais  soient  respectés. 


Rôles  de  relation 


PROMOTEUR  -  Extraverti,  enthousiaste  et  communicatif.  Il  explore  les 
opportunités  et  développe  les  contacts.  Il  tire  profit  des  idées  et  des 
informations  du  monde  extérieur. 


COORDINATEUR  -  Mature,  confiant.  Attentif  aux  autres  et  diplomate.  Il 
clarifie  les  objectifs  et  fait  progresser  les  prises  de  décision.  Il  s'assure  que 
les  efforts  et  les  qualités  des  coéquipiers  sont  utilisés  au  mieux. 


SOUTIEN  -  Sociable,  sensible  et  conciliant.  Il  est  attentif  aux  autres  et  à 
leurs  besoins.  Il  est  plein  de  tact.  A  l'écoute,  il  évite  les  frictions  et 
recherche  les  consensus.  Il  bâtit  le  relationnel  dans  l'équipe. 


On  se  gardera  bien  avec  ce  type  de  modèle  d'associer  des  points  négatifs  à  chaque  rôle 
puisque  chacun  représente  un  rôle  de  compétences.  Si  on  désire  associer  des  rôles 
d'incompétences  à  chacun  des  collaborateurs,  il  est  aussi  de  nombreux  modèles  théoriques 
pour  cela  équivalents  à  celui-ci. 

Je  propose  un  test  simple  pour  vérifier  le  niveau  de  rigueur  de  travail  d'une  ressource:  Donnez 
à  chaque  membre  de  l'équipe  de  projet  un  document  papier  de  5  pages  résumant  le  projet  et  à 
la  dernière  page  laissez  un  espace  vide  pour  la  date,  l'heure  et  la  signature  comme  quoi  la 
ressource  approuve  ce  qu'elle  aura  lu  (mais  n'en  faites  pas  mention  lorsque  vous  distribuez  le 
document) 

Quand  les  documents  vous  reviendront  vous  aurez: 

1.  Ceux  qui  n'ont  rempli  ni  la  date,  ni  l'heure  ni  la  signature. . . 

2.  Ceux  qui  auront  rempli  la  date  et  la  signature 

3.  Ceux  qui  auront  tout  rempli  correctement 
Après  vous  en  tirez  les  conclusions  que  vous  voulez. . . 

Un  autre  exemple  pour  distinguer  les  employés/cadres  expérientiels  (qui  se  fient  sur  l'intuition 
et  des  méthodes  heuristiques)  et  les  employés/cadres  cognitifs  (qui  utilisent  une  réflexion 
poussée  dans  chaque  situation  proche  de  la  méthode  scientifique)  c'est  de  demander  à  chacun 
comment  ils  feraient  pour  estimer  la  durée  d'un  projet...  Vous  risquez  de  tomber  de  haut  la 
majorité  du  temps  en  entendant  les  réponses... 
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8.4.5  Comportements 

Je  tiens  à  indiquer  les  types  de  comportements  relatifs  à  divers  domaines  tels  qu'indiqués  dans 
le  très  officiel  Swiss  National  Compétence  Baseline  Version  4.0  de  2007  (basé  sur  IPMA) 
relatif  au  responsable  de  projet  mais  dont  une  grande  partie  implique  aussi  les  ressources  et  la 
direction. 

La  longue  liste  de  catégories  ci-dessous,  dont  une  relecture  périodique  est  fortement 
conseillée,  est  très  exhaustive  mais  la  justesse  de  ce  type  de  catégorisation  est  ouverte  bien 
évidemment  à  nombre  de  débats  enflammés. . .: 

Leadership 


Sait  déléguer  des  tâches,  fait  confiance  aux 
autres,  encourage  leur  développement  et  leur 
capacité  à  satisfaire  les  exigences. 

Ne  délègue  pas,  ne  forme  et  ne  développe 
pas  les  autres. 

A  une  vision,  l'exprime  clairement,  la  défend 
et  lui  donne  vie. 

Est  parfois  égocentrique,  tend  à 
l'inconstance,  n'a  pas  de  vision,  ne  défend  pas 
ses  idées. 

A  de  l'autorité  naturelle,  est  écouté  et  inspire 
confiance. 

Doit  se  justifier  en  permanence,  suscite  le 
doute. 

Délègue  des  lots  de  travaux  SMART 
(spécifiques,  mesurables,  atteignables, 
réalistes,  définis  dans  le  temps)  et  conformes 
aux  aptitudes  de  ses  collaborateurs;  les  laisse 
faire  les  choses  à  leur  manière. 

N'applique  pas  les  principes  SMART  et 
restreint  la  marge  de  manœuvre  de  ses 
subordonnées  en  leur  imposant  des 
obligations  et  des  contrôles. 

Est  un  animateur  habile. 

Ne  sait  pas  animer  un  processus  ou  un 
dialogue  conflictuel. 

Allie  pouvoir  et  charisme. 

Semble  faible  et  insignifiant. 

Inspire  les  autres,  les  rend  fiers  de  travailler 
avec  lui. 

Sa  personnalité  n'est  pas  attrayant  pour 
autrui. 

Sait  récompenser  et  prend  des  mesures 
correctives  d'une  manière  compréhensible 
pour  les  membres  de  l'équipe. 

Récompense  et  prend  des  mesures  corrective 
à  mauvais  escient  et  de  manière  inadéquate. 

Assume  la  responsabilité  et  les  missions  en 
conséquence. 

Délègue  directement  toutes  les 
responsabilités  et  tous  les  objectifs  aux 
membres  de  l'équipe. 

Préserve  les  objectifs  du  projet  et  défend  les 
membres  de  l'équipe  dans  la  négociation  de 
changements. 

Donne  tort  aux  membres  de  l'équipe  et  laisse 
d'autres  faire  pression  pour  changer  les 
objectifs,  les  missions  ou  la  description  du 
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projet. 

Contrôle  le  comportement  des  membres  de 
l'équipe  de  projet  sciemment  de  façon 
constructive,  est  discipliné  et  consacre  du 
temps  à  la  communication. 

Ne  sait  pas  vraiment  que  est  l'effet  d'un 
contrôle,  prétend  manque  de  temps,  évite  les 
discussions. 

Implique  les  membres  de  l'équipe  dans  les 
décisions  ou  a  de  bonnes  raisons  de  les 
prendre  seul. 

Prend  toutes  les  décisions  seul  et  ne  les 
communique  pas  aux  membres  de  l'équipe  de 
projet. 

Adapte  son  style  de  direction  à  la  situation  de 
l'équipe  et  du  travail  et  par  d'autres  parties 
intéressés. 

Les  autres  considèrent  que  son 
comportement  est  inadéquat;  il  ne  manifeste 
aucun  comportement  de  direction  envers 
l'équipe  et  les  autres  parties  intéressées. 

Agit  et  parle  avec  calme,  formule  ses 
réponses  avec  clarté  et  autorité. 

Parle  trop  vite,  en  phrases  incomplètes  et  fait 
des  gestes  inappropriés  ou  utilise  un  langage 
corporel  inadéquat. 

Reste  calme  même  en  cas  de  crise,  évite  la 
panique  visible. 

Panique  et  perd  le  contrôle  de  soi. 

Tableau  4  Conduite  (Leadership) 

Engagement  et  motivation 


Gère  activement  la  prise  en  compte  d'intérêts 
différents. 

Limite  son  engagement  à  des  intérêts 
personnels  ou  à  ceux  du  projet;  n'est  pas 
conscient  des  intérêts  d'autrui. 

Apprécie  les  initiatives  et  l'engagement 
d'autrui. 

Limite  ses  collaborateurs  à  des  tâches  bien 
définies,  ne  récompense  pas  l'initiative 
personnelle,  ne  délègue  pas,  s'arroge  tout  le 
mérite,  rejette  la  faute  sur  les  autres. 

Est  positif  et  enthousiaste,  travaille  avec 
bonne  humeur,  est  axé  sur  les  performances 
sans  jamais  perdre  de  vue  les  objectifs  du 
projet. 

Rend  ses  collaborateurs  nerveux,  se 
concentre  surtout  sur  les  risques  et  les 
problèmes  ou,  lorsqu'il  s'enthousiasme,  perd 
de  vue  les  objectifs  du  projet. 

Réserve  un  accueil  positif  à  la  critique,  qu'il 
considère  comme  une  forme  d'engagement. 

Ne  sait  pas  gérer  la  critique  et  ne  l'exploite 
pas  pour  le  bien  du  projet. 

Pratique  une  gestion  active  de  la  motivation. 

Ne  se  préoccupe  pas  des  baisses  de 
motivation. 

Fait  des  plans  de  projet  l'affaire  de  toute 
l'équipe. 

Impose  les  plans  de  projet  à  l'équipe. 

Faire  preuve  d'un  comportement  positif  et 

Rédige  des  rapports  concernant  des 
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réaliste,  recherche  des  solutions  en  cas  de 
problème. 

problèmes  sans  proposer  de  solutions,  attend 
que  les  auteurs  prennent  des  décisions. 

Donne  de  l'énergie  à  l'équipe  et  utilise 
l'énergie  de  tous  les  membres  de  l'équipe. 

Travaille  essentiellement  seul  ou  avec 
quelques  amis  proches. 

Sait  où  et  comment  faire  participer  les  autres. 

Travaille  seul. 

Faire  preuve  de  volonté  pour  le  bien  du 
projet. 

Baisse  facilement  les  bras  et  perd  vite  sa 
motivation. 

Encourage  le  travail  en  équipe  et  la 
collaboration  interdisciplinaire. 

Empêche  ou  entrave  le  travail  en  équipe 
constructif,  évite  la  collaboration 
interdisciplinaire. 

Tableau  5  Engagement  et  motivation 


Maîtrise  de  soi 


Contrôle  ses  émotions,  est  très  résistant  à  la 
frustration. 

Paraît  lunatique,  irritable  et  irrationnel,  perd 
souvent  son  sang-froid. 

A  une  attitude  positive  par  rapport  à  la 
critique  constructive,  réagit  calmement  aux 
attaques  personnelles,  n'est  pas  rancunier. 

Se  vexe  ou  se  révolte  face  à  la  critique,  réagit 
de  manière  émotionnelle  et  incontrôlée,  est 
rancunier. 

Est  capable  de  discuter  de  problèmes  au  sein 
de  l'équipe;  fait  office  de  médiateur,  discute. 

Ignore  les  conflits,  ne  sait  pas  ce  qui  se  passe 
au  niveau  informel,  provoque  le  refus. 

Encourage  une  culture  de  discussion 
constructive  au  sein  de  l'équipe,  cherche 
toujours  le  consensus. 

Néglige  les  conflits,  utilise  son  pouvoir, 
démolit  les  adversaires,  les  humilie. 

Concilie  vie  professionnelle  et  privée. 

Est  un  drogué  du  travail,  ne  s'intéresse  qu'au 
travail,  néglige  sa  vie  privée. 

Tableau  6  Maîtrise  de  soi 


Relaxation  et  maîtrise  du  stress 


Agit  et  réagit  avec  décontraction 

Est  trop  tendu  pour  maîtriser  la  situation 

Pratique  l'humour  pour  le  bien  du  projet 

Ne  pratique  pas  l'humour  ou  alors  de  manière 
inadéquate 

Est  capable  de  neutraliser  une  situation 

Aggrave  la  situation  en  intervenant  au 
mauvais  moment  ou  de  manière  inadéquate 

Est  constamment  conscient  des  situations 
potentiellement  difficiles,  intervient  de  façon 

Ne  s'aperçoit  pas  que  quelque  chose  ne  va 
pas,  n'est  pas  créatif  dans  ses  interventions  et 

Ingénierie  de  Gestion  de  projets 


178/547 


Vincent  ISOZ 


inattendue  et  peu  conventionnelle  pour 
obtenir  des  résultats  optimaux 

utilise  des  méthodes  exclusivement 
conventionnelles 

Remarque  les  tensions  interpersonnelles  et 
est  capable  de  les  atténuer  ou  d'y  remédier 

Refuse  de  reconnaître  les  tensions 
interpersonnelles  et  ne  prend  aucune  mesure. 

Parle  ouvertement  de  son  propre  stress  et  de 
celui  des  autres. 

N'est  pas  capable  d'avouer  son  propre  stress 
et  ne  prend  pas  ses  symptômes  au  sérieux. 

Tient  compte  des  situations  de  stress  et  essaie 
de  les  atténuer. 

Provoque  inutilement  du  stress  et  ne 
recherche  pas  d'aide  en  situation  de  stress. 

Est  capable  d'évaluer  son  propre  bien-être  et 
applique  des  techniques  de  relaxation  avant 
que  le  stress  le  submerge. 

N'est  capable  ni  d'évaluer  son  état  ni  de 
prendre  les  mesures  nécessaires. 

Budgétise  et  planifie  les  activités  de 
recherche  de  cohésion  de  l'équipe  et  des 
événements  sociaux  et  des  loisirs  extra¬ 
professionnels. 

Ne  tient  pas  compte  des  activités 
extraprofessionnelles. 

Tableau  7  Relaxation  et  maîtrise  du  stress 

Ouverture  d'esprit 


Est  souple,  s'adapte  aisément  aux 
changements  tout  en  tenant  compte  des 
intérêts  du  projet. 

Est  rigide  et  refuse  les  changements,  néglige 
les  intérêts  du  projet. 

Est  ouvert  envers  les  différences  dues  à  l'âge, 
à  l'orientation  sexuelle,  à  la  religion,  à  la 
culture  et  au  handicap. 

Ignore  les  différences  dues  à  l'âge,  à 
l'orientation  sexuelle,  à  la  religion,  à  la 
culture  et  au  handicap. 

Gère  la  coopération,  dirige  l'équipe. 

Est  axé  sur  son  travail,  gère  l'équipe 
mécaniquement  et  sans  émotions. 

Bénéficie  d'une  vase  culture  générale  (non 
limite  au  management  de  projet)  et  sait 
adapter  sa  manière  de  communiquer  à  ses 
interlocuteurs  de  sorte  à  être  compris. 

Est  incapable  de  communiquer  en  tenant 
compte  de  la  manière  de  penser  d'autrui,  n'est 
pas  bien  compris. 

Encourage  l'ouverture  d'esprit  par  une 
ambiance  au  travail  agréable,  un  habillement 
esthétique  et  un  aspect  soigné. 

Décourage  l'ouverture  d'esprit  en  négligeant 
son  habillement  et  son  aspect  et  en 
détériorant  l'ambiance  de  travail. 

A  une  attitude  ouverte  et  positive,  est  un 
optimiste  réaliste. 

Fait  bande  à  part,  ignore  les  autres,  semble 
absent. 

Suscite  la  confiance,  est  plein  de  bonnes 
volonté. 

Paraît  méfiant. 
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Aborde  les  autres  activement  et  dans  un 
esprit  positif,  est  accessible. 

Attend  que  les  autres  prennent  l'initiative,  est 
réservé  et  peu  sûr  de  lui-même. 

Gère  activement  les  parties  intéressées, 
entretient  des  contacts  formels  et  informels 
avec  les  parties  intéressées. 

Ne  gère  pas  activement  les  parties 
intéressées,  évite  le  contact  avec  elles,  ne 
consacre  pas  de  temps  aux  contacts 
informels. 

Accepte  tous  les  membres  de  l'équipe,  tolère 
et  encourage  les  opinions  différentes  au  sein 
de  l'équipe  et  stimule  la  participation  active. 

Fait  sentir  son  aversion  aux  autres,  ne 
fonctionne  que  selon  des  principes,  croit  tout 
savoir  et  ne  cherche  pas  à  connaître  l'opinion 
d'autrui. 

Accepte  et  respecte  les  minorités,  laisse  les 
autres  avoir  du  succès. 

Est  axé  sur  les  structures  de  pouvoir  en  place. 

Tableau  8  Ouverture  d'esprit 

Ouverture  d'esprit 


Est  créatif,  accepte  les  défis  et  est  ouvert  aux 
idées  nouvelles. 

S'accroche  aux  solutions  connues  et 
éprouvées  et  à  peur  de  l'inconnu. 

Est  optimiste  quant  au  fait  que  des  idées 
nouvelles  se  traduiront  par  des  solutions 
applicables. 

Rejette  les  idées  sans  les  avoir  examinées  en 
déclarant  qu'elles  sont  impraticables. 

Aplanit  les  différends  en  définissant  une 
solution  nouvelle  qui  peut  être  réalisée 
moyennant  le  respect  des  opinions 
différentes. 

N'est  pas  en  mesure  d'intégrer  des  idées 
différentes.  Fait  un  choix  entre  des  opinions 
divergentes  et  crée  des  tensions  au  sein  de 
l'équipe. 

Trouve  des  solutions  en  appliquant  des  idées 
nouvelles,  des  outils  et  du  bon  sens  dans  de 
nouveaux  domaines. 

Ne  peut  pas  acceptes  les  idées  nouvelles  ou 
les  outils  nouveaux  comme  un  moyen  de 
résoudre  des  problèmes  difficiles.  N'utilise 
pas  le  bon  sens. 

Incite  les  collaborateurs  à  exposer  leurs 
idées,  reconnaît  les  opportunités  et  organise 
un  processus  rationnel  de  recherche  créative 
de  solutions. 

Recherche  toujours  des  solutions  éprouvées, 
ne  sait  pas  gérer  l'incertitude  et  n'est  pas 
capable  de  diriger  adéquatement  un 
processus  créatif  de  recherche  de  solutions. 

Gère  activement  les  descriptions  de 
prestations  et  les  changements. 

Refuse  tout  ce  qui  dépasse  la  définition 
originale  des  prestations. 

Est  réceptif  au  langage  corporel  et  aux 
sentiments,  utilise  son  intuition  pour  résoudre 
les  problèmes  et  dans  le  cadre  des  relations 
humaines. 

N'accepte  que  ce  qui  est  prévu,  néglige  les 
intuitions  et  les  sentiments.  S'en  tient  à  la 
logique  et  aux  relations  fonctionnelles. 
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Écoute  sa  propre  intuition  et  l'exploite,  voit 
en  ses  idées  une  source  de  créativité. 

Refuse  l'intuition. 

Utilise  des  approches  non  conventionnelles 
pour  le  bien  du  projet.  Prend  des  décisions 
créatives  pour  réduire  les  risques. 

Accepte  toujours  le  statu  quo  même  si 
l'avenir  du  projet  est  en  jeu.  A  une  aversion 
au  risque. 

Tableau  9  Créativité 

Orientation  résultats 


Se  comporte  en  entrepreneur 

Se  content  de  suivre  les  ordres 

Est  capable  de  régler  des  questions 

Ne  règle  pas  définitivement  les  questions. 

Recherche  constamment  des  possibilités 
d'amélioration  et  remet  le  statu  quo  en 
question. 

Accepte  les  choses  telles  qu'elles  sont.  Ne 
remet  pas  le  statu  quo  en  question. 

Recherche  toujours  des  solutions  qui  ne 
nécessitent  pas  de  modification  des  objectifs. 

N'est  pas  créatif  dans  la  recherche  de 
solutions.  Transforme  chaque  problème  en 
un  changement. 

Exploite  les  opportunités  sans  négliger  les 
risques. 

A  une  aversion  au  risque  et  ignore  les 
opportunités. 

Gère  les  modifications  de  manière  adéquate; 
informe  dès  que  possible  lorsqu'un  plan  ne 
peut  être  respecté,  propose  des  alternatives. 

La  direction  a  l'impression  de  contrôler  le 
projet. 

Promet  de  nouvelles  fonctionnalités  ou 
prestations  sans  s'assurer  qu'il  pourra 
procéder  aux  changements  sans  ressources 
supplémentaires.  Tarde  à  informer  la 
direction  de  changements  inattendus.  La 
direction  n'a  pas  l'impression  de  contrôler  le 
projet. 

Surveille  les  innovations  et  les  opportunités 
nouvelles  (p.  ex.  technologies,  marchés, 
concurrents  nouveaux)  susceptibles 
d'influencer  le  projet  et  y  réagit  de  manière 
appropriée. 

Reste  dans  les  limites  convenues  et  laisse 
passer  des  innovations  et  des  opportunités 
majeures  qui  influencent  le  projet. 

Gère  activement  les  parties  intéressées. 

Néglige  les  parties  intéressées. 

Parvient  à  gérer  les  attentes  de  manière 
transparente  et  efficace;  les  satisfait  ou  les 
dépasse. 

Ne  gère  pas  les  attentes  de  manière 
transparente  ou  suscite  des  attentes 
disproportionnées. 

Est  conscient  des  détails  sans  pour  autant 
perdre  la  maîtrise  de  l'ensemble. 

Ignore  des  détails  importants  et  perd  la 
maîtrise  de  l'ensemble. 

Tableau  10  Orientation  résultats 
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Efficience 


Se  prononce  clairement  sur  la  productivité  et 
l'efficience  dans  le  projet  et  se  comporte  de 
façon  correspondante. 

Ne  se  prononce  pas  clairement  ou  ne 
communique  pas  sur  la  productivité  et 
l'efficience,  ne  montre  pas  l'exemple. 

Sait  déléguer  et  fait  confiance  aux  autres, 
pratique  le  management  par  exception. 

Essaie  de  tout  faire  lui-même  et  a  pour 
confiance  en  autrui. 

Ouvre  les  réunions  à  l'heure  convenue  et  les 
termine  le  plus  rapidement  possible. 

Arrive  en  retard  aux  réunions,  les  laisse  se 
prolonger  inutilement. 

Vise  l'amélioration  constante,  incite  ses 
collaborateurs  à  faire  de  même. 

Néglige  les  améliorations.  Est  facilement 
satisfait  de  ses  collaborateurs. 

Possède  l'énergie  et  l'opiniâtreté  nécessaires  à 
mener  à  bien  ce  qu'il  entreprend. 

Semble  lent,  n'a  pas  de  patience,  abandonne 
rapidement. 

Encourage  l'enthousiasme,  demande  des 
contributions  positives  et  est  ouvert  à  la 
critique. 

Est  incapable  de  motiver,  critique 
injustement  et  n'est  pas  ouvert  à  la  critique. 

Remarque  l'utilisation  inefficient  de 
ressources  et  prend  les  mesures  nécessaires. 

Ignore  l'inactivité  et  ne  réagit  pas  aux 
avertissements  des  autres. 

Sait  tirer  parti  de  l'efficience. 

Pratique  l'efficience  à  mauvais  escient,  induit 
ses  collaborateurs  en  erreur. 

Tableau  11  Efficience 

Conflits  et  crises 


Est  capable  de  discuter  de  situations  avec  son 
équipe;  intervient  comme  médiateur,  discute 
et  est  conscient  des  conflits  latents. 

Ignore  les  conflits  latents,  en  sait  pas  ce  qui 
se  passe  au  niveau  informel,  provoque  des 
divergences. 

Est  accessible,  prend  toujours  le  temps 
d'écouter  en  cas  de  crise  ou  de  conflit, 
collabore  avec  l'équipe  et  avec  d'autres 
parties  intéressées. 

S'occupe  d'autre  chose  et  s'isole  en  cas  de 
conflit  ou  de  crise,  ne  s'entretient  avec  les 
autres  qu'au  niveau  formel.  N'a  aucun  lien 
informel  ou  social  avec  son  équipe. 

Considère  l'incertitude  comme  un  défi. 

Laisse  les  risques  et  les  problèmes 
s'accumuler. 

Est  ouvert  aux  intérêts  contradictoires  en  cas 
de  cirse  et  de  conflit. 

Provoque  activement  au  sein  de  l'équipe  des 
divergences  d'opinion  qui  peuvent  dégénérer 
en  conflit  ou  en  crise. 

A  une  attitude  positive  par  rapport  à  la 

Se  vexe  ou  se  révolte  face  à  la  critique,  réagit 

Ingénierie  de  Gestion  de  projets 


182/547 


Vincent  ISOZ 


critique  constructive,  réagit  calmement  aux 
attaques  personnelles,  n'est  pas  rancunier. 

de  manière  émotionnelle  et  incontrôlée,  est 
rancunier. 

Est  équitable,  accepte  les  propositions  des 
autres  sans  rancune. 

Impose  ses  propositions  aux  dépens  des 
autres,  refuse  les  réactions  constructives. 

Fait  la  différence  entre  les  problèmes  de 
relations  humaines  et  les  problèmes  de  travail 
et  les  résout  dans  l'ordre  qui  convient. 

Confond  relations  personnelles  et  problèmes 
de  contenu. 

Est  sûr  de  lui  et  positif,  respecte  la  fonction 
la  personnalité  de  chacun. 

Est  arrogant,  semble  fragile,  manipule  les 
autres  membres  de  l'équipe. 

Profite  des  conflits  pour  faire  avancer  le 
projet. 

Néglige  les  conflits  potentiels  ou  latents, 
n'est  pas  prêt  à  défendre  le  projet  jusqu'au 
bout. 

Tableau  12  Conflits  et  crises 

Conflits  et  crises 


Est  fiable,  autrement  dit  fournit  la  prestation 
promise  convenue  au  moment  convenu,  avec 
la  qualité  convenue  et  avec  le  budget 
convenu. 

N'est  pas  faible,  autrement  dit  fournit  une 
prestation  inférieure  à  celle  convenue,  n'est 
pas  ponctuel  ou  dépasse  le  budget,  sacrifie  la 
qualité. 

Lorsque  la  situation  dépasse  les  tolérances 
admises  du  projet,  fournit  au  mandant 
(soumissionnaire)  des  rapports  bien 
documentés  en  temps  utile. 

Sa  devise  est  "laisser  aller,  laisser  faire". 

Tarde  tellement  à  fournir  un  rapport  au 
mandant  (soumissionnaire)  que  celui-ci  n'a 
plus  la  possibilité  d'influencer  le  résultat. 

Est  digne  de  confiance,  utilise  avec 
discrétion  ce  qu'on  lui  a  dit  en  confidence. 

Ne  semble  pas  fiable,  trahit  la  confiance  des 
autres. 

Se  sent  responsable  du  succès  du  projet  au 
nom  de  toutes  les  parties  intéressées. 

Rejette  toujours  la  faute  sur  les  autres. 

Assume  la  responsabilité  de  l'ensemble, 
définit  correctement  les  sous-domaines  de 
compétence. 

Répercute  directement  tous  les 
enseignements  pris  envers  le  mandant 
(soumissionnaire)  et  tous  les  objectifs  sur  les 
membres  de  son  équipe. 

Contrôle  le  comportement  des  membres  de 
l'équipe  de  projet  d'une  manière  consciente  et 
constructive,  est  discipliné  et  consacre  du  te 
temps  à  la  communication. 

N'est  pas  conscient  des  conséquences  de  ses 
activités  de  contrôle,  prétexte  le  manque  de 
temps,  ne  communique  pas  de  manière 
adéquate. 

Transmet  toutes  les  informations  de  manière 
adéquate. 

A  des  difficultés  à  transmettre  l'information. 

Tableau  13  Fiabilité 
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8.4.6  Caractères 

Voici  une  figure  que  j'ai  prise  de  la  présentation  d'une  entreprise  Xtrem7  et  que  je  trouve  très 
bien  faite.  Elle  résume  et  différencie  ce  qu'est  une  bonne  ressource,  d'une. . . .  moins  bonne  en 
théorie  dans  un  contexte  idéal  et  selon  les  standards  actuels  de  notre  société. 


En  ce  qui  concerne  la  ressource  idéalisée: 

REALISTE 

•  Analyse,  Structuration 
»  Productivité 
■  Définition  dTobjectif 
»  Optimisation  du  temps 

•  Evaluation  (factuelle) 

CONFORME 

•  Cadre  de  référence  (certitudes) 

•  Ligne  de  conduite 

•  Règles  du  jeu,  Fermeté 

•  Esprit  critique  (Jugement) 

•  Conservation  (de  l'existant) 


Jft  PRUDENT 
IgpE?  •  Sécurité  i  Prudence 
•  Exécution  /  Minutie 


1 î> 


Vérification 

Discrétion 


COMBATTANT 

•  Hardiesse,  Témérité 

•  Combativité 

•  Bravoure 
■  Instinct 


CREATIF 

•  Vision  (Anticipation) 

•  Stratégie,  Imaginaire  1 

•  Créativité  (Innovation) 

•  Elaboration  de  synthèse 

•  Pensée  latérale  (liens) 

•  Métaphore  (communication) 

SPONTANE 

•  Expérimentation 

•  Sens  du  plaisir 

•  Enthousiasme 

•  Vivacité,  Audact 

•  Charisme,  Séduction 
EMPATHIQUE 

•  Interaction  humaine 
«  Sentiment  -  feeling  J 

•  Soutien,  Empathie^* 

•  Harmonie,  Intimité 


Figure  15  Ressource  idéalisée 


Et  la  moins  adaptée. . .  : 
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REALISTE 


CREATIF 


•  Imperméable  à  l'irrationnel 

*  Froid,  distant,  déshumanisé 

•  Trop  direct  (communication) 
»  Involontairement  brutal 

*  Naïf 

CONFORME 

•  Dominateur,  persécuteur 

•  Dévalorisant,  brimant, 
inhibant,  tyrannique 

•  Censurant  (créativité) 

•  Rigide,  résistant 
(changement) 

PRUDENT 

•  Pinailleur 

•  Entêté 

•  Timoré,  inhibé,  subissant 

•  Auto  dépréciatif,  résigné 


•  Illusoire,  utopique 


Fuit  dans  l’imaginaire 

Complexe,  difficile  à 
suivre 

Inapplicable 
Supérieur,  arrogant 


SPONTANE 

•  Anti  conventionnel 

•  Dispersé,  impétueux, 
exalté,  voire  fanatique, 

•  Egocentrique  {se  sert 
d’autrui) 


•  Intransigeant,  épuisant 


•  Excessivement  confiant 


EMPATHIQUE 


COMBATTANT 

•  Impulsif,  hyper  réactif, 

•  Rebelle,  contestataire, 
Opposé  à  l’autorité, 

•  Se  sent  attaqué,  écorché  vif 

•  Irréfléchi,  incontrôlé 

•  Exacerbé  agressif, 
destructeur 


Subjectif,  chimérique 
(lecture  de  pensées,  films) 

Sur  protecteur,  étouffant, 

Envahissant,  fait  à  la  place 
de,  fusionnel, 

En  attente  de  reconnaissan¬ 
ce,  vite  blessé,  susceptible 

Crée  des  précédents 


Figure  16  Ressource  inadaptée... 


Enfin  comme  souvent  voici  deux  petites  citations  qui  peuvent  amener  réfléchir  un  peu: 


Je  préfère  être  détesté  pour  ce  que  je  suis  Que  d’être  aimé  pour  ce  que  je  ne  suis  pas! 

G.  Simenon 


et: 


Vous  pouvez  tromper  quelques  personnes  tout  le  temps.  Vous  pouvez  tromper  tout  le 
monde  un  certain  temps.  Mais  vous  ne  pouvez  tromper  tout  le  monde  tout  le  temps. 

A.  Lincoln 


8.4.7  Théorie  X  et  Y 

Les  théories  X  et  Y  sont  des  théories  développées  dans  les  années  1960  par  Douglas  McGregor 
et  utilisées  en  ressources  humaines  et  en  comportement  de  l'organisation  (attention!  il  ne  s'agit 
pas  d'une  théorie  dans  le  sens  scientifique  du  terme  mais  d'une  "observation"!).  Les  deux 
théories  s'opposent  entre  elles.  La  première  suppose  que  l'homme  n'aime  pas  travailler,  la 
seconde  affirme  le  point  de  vue  inverse.  Ces  deux  théories  sont  issues  d'observations 
empiriques  et  sont  formulées  de  manière  à  rendre  compte  des  comportements  observés  dans 
les  organisations,  selon  les  postulats  des  dirigeants. 

On  peut  classifier  majoritairement  les  employés  en  deux  catégories  dont  la  X  représente  la 
majorité  salariale: 

•  L'être  humain  moyen  n'aime  pas  le  travail  et  l'évitera  s'il  le  peut. 

•  Du  fait  de  leur  aversion  à  l'égard  du  travail,  la  plupart  des  gens  doivent  être  contrôlés 

•  Les  travailleurs  ne  fournissent  l'effort  dans  les  temps  attendu  que  sous  la  contrainte 
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•  L'humain  moyen  préfère  être  dirigé 

•  L'humain  moyen  n'aime  pas  ou  évite  les  responsabilités 

•  L'humain  moyen  désire  la  sécurité  par-dessus  tout. 

•  L'humain  moyen  déploie  vraiment  son  intelligence  que  pour  contourner  les  règlements 

•  L'humain  moyen  ne  va  pas  s'impliquer  personnellement  ni  être  innovant/créateur 

Ensuite  vient  une  deuxième  catégorie  dont  Y  représente  la  minorité  salariale  (moins  de  5% 
souvent)  et  dont  les  présupposés  sont  que  les  membres  de  cette  catégorie: 

•  S'impliquent  dans  la  vie  de  l'organisation  comme  dans  sa  propre  vie  privée 

•  Ne  travaillent  pas  que  pour  le  salaire  mais  pour  le  plaisir  et  pour  se  sentir  utile 

•  Sont  satisfaits  et  fiers  de  travailler  pour  leur  employeur 

•  Apprennent  seuls  et  deviennent  en  une  dizaine  d'années  des  experts  dans  leur  domaine 

•  Cherchent  à  prendre  des  responsabilités 

•  Proposent  des  idées,  des  améliorations 

•  Préfèrent  s'auto-organiser/s'auto-gérer 

Il  y  a  encore  une  troisième  catégorie  que  sont  les  HP  (hauts-potentiels)  qui  représentent 
souvent  au  maximum  1%  de  la  masse  salariale. 

8.4.8  Conflits 

La  gestion  de  conflit  couvre  un  large  éventail  de  sujets,  qui  va  des  conflits  interpersonnels  aux 
conflits  internes  d'une  organisation,  en  passant  par  les  conflits  qui  concernent  les  domaines  de 
la  gestion. 

L'entreprise  qui  insiste  à  tirer  une  ligne  de  démarcation  entre  les  exécutants  et  les  penseurs 
risque  fort  de  se  voir  défendre  par  des  idiots  et  dirigés  par  des  lâches. 

Quand  vous  faites  face  à  un  conflit,  la  première  question  à  laquelle  vous  devez  répondre  est: 
De  quel  type  de  conflit  s'agit-il?  et  comme  le  recommande  le  PMI,  la  solution  à  un  conflit 
dans  le  cadre  d'un  projet  devrait  toujours  aller  vers  une  solution  qui  est  favorable  au  client! 

On  peut  diviser  les  conflits  probablement  en  trois  types  principaux  (donc  ils  sont  non 
exhaustifs!): 

1.  Conflits  d'intérêts 

2.  Conflits  de  besoins 

3.  Conflits  d'opinions 

Il  peut  être  parfois  difficile  de  discerner  le  type  de  conflit  auquel  vous  avez  à  faire. 

Cependant,  il  est  important  que  vous  essayiez  d'accéder  au  cœur  du  problème  car  cela  vous 
aidera  à  décider  ce  qu'il  convient  de  faire  au  sujet  de  ce  problème. 

Obtenir  un  succès  en  gestion  de  conflit  nécessite  des  choix  éclairés.  La  liste  ci-dessous  peut 
vous  aider  à  décider  le  style  de  gestion  de  conflit  à  choisir  pour  une  situation  donnée.  La  liste 
indique  aussi  qu'il  ne  faut  pas  toujours  se  cantonner  à  un  même  style.  Si  vous  gérez  souvent 
dans  un  style  coopératif  en  face  à  face,  vous  gaspillerez  beaucoup  de  temps  et  d'énergie  s'il 
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s'agit  de  traiter  de  petits  problèmes  qui  ne  nécessitent  pas  ce  style  d'approche.  Si  vous  utilisez 
toujours  des  approches  de  non-confrontation  et  non-coopération,  vous  n'obtiendrez  jamais  ce 
que  vous  et  les  bénéficiaires  du  projet  veulent,  et  dont  ils  ont  besoin  (modèle  de  Hodgson  - 
1994): 

•  Collaboration  (problem  solving):  un  style  de  face  à  face  coopératif. 

Adapté  quand  les  deux  parties  veulent  trouver  une  solution  et  quand  il  faut  qu'elles 
soutiennent  la  solution.  C'est  un  style  proche  de  la  situation  gagne-gagne  en 
négociation. 

•  Contestation  (forcing):  un  style  de  face  à  face  non-coopératif. 

Adapté  quand  des  actions  décisives  rapides  sont  nécessaires  (par  exemple,  cas  urgents). 

•  Acceptation  (smoothing):  un  style  coopératif,  sans  face  à  face. 

Adapté  quand  on  s'aperçoit  qu'on  s'est  trompé,  ou  que  le  problème  a  moins  importance 
pour  vous,  ou  dans  le  cas  où  vous  voulez  augmenter  votre  crédit  aux  yeux  des  autres 
parties  et  /  ou  des  négociateurs. 

* 

•  Evitement  (withdrawal):  un  style  de  non-coopération,  sans  face  à  face. 

Adapté  dans  le  cas  d'un  problème  sans  importance:  vous  avez  peu  de  pouvoir  et  vous  ne 
voyez  aucune  possibilité  de  changer  les  choses  (par  exemple,  les  problèmes  de  niveau 
national,  ou  liés  aux  grandes  organisations). 

•  Compromis:  un  style  à  mi-chemin  de  tous  les  autres  et  qui  intègre  des  éléments  de  tous 
les  autres. 

Adapté  dans  le  cas  de  problèmes  d'importance  modérée. 

Dans  tous  les  cas,  chaque  discussion,  chaque  décision,  chaque  promesse  doit  être  inscrite  dans 
un  procès-verbal  signée  par  chacune  des  parties. 

La  première  étape  en  gestion  de  conflit  est  d'analyser  le  type  de  conflit.  Comme  indiqué  plus 
haut,  c'est  une  information  importante  pour  vous  aider  à  maîtriser  le  conflit. 

Pour  analyser  et  gérer  le  conflit,  vous  pouvez  utiliser  la  liste  de  contrôle  suivante: 

1.  Quel(s)  est  (sont)  le(s)  vrai(s)  problème(s)?  Que  se  passe-t-il  réellement?  Quelles  sont 
les  personnes  réellement  impliquées?  A-t-on  besoin  d'information  ou  d'analyse 
supplémentaires  pour  clarifier  les  problèmes?  Est-ce  que  les  parties  ont  la  capacité  de 
comprendre  des  documents  importants? 

Ces  questions  vous  aideront  à  éviter  de  parler  des  symptômes  et  au  contraire  à  vous 
concentrer  sur  le  cœur  du  conflit  -  le(s)  vrai(s)  problème(s).  Vous  pouvez  tenter 
d'analyser  le  conflit  tout  seul  ou  avec  les  membres  de  votre  équipe.  Si  vous  discutez  de 
manière  ouverte  avec  l'autre  partie  impliquée  dans  le  conflit,  vous  pouvez  aussi 
essayer  d'inciter  les  parties  à  décrire  leur  vision  de  ce  qui  est  au  cœur  du  problème  et 
d'organiser  une  visite  de  site  afin  d'établir  les  faits  sur  place. 
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2.  Que  veulent  réellement  les  personnes  impliquées? 

S'il  vous  est  possible  de  définir  un  but  commun  pour  les  personnes  impliquées,  cela 
facilitera  le  travail  de  recherche  de  solutions  sur  lesquelles  les  deux  parties 
s'accorderont.  Même  si  cela  n'est  pas  possible,  il  reste  important  que  les  buts  des  deux 
parties  soient  définis  pour  une  compréhension  réciproque. 

3.  Le  conflit  est-il  d'une  taille  gérable  ou  doit-il  être  découpé  en  plusieurs  petits 
problèmes?  Si  vous  vous  impliquez,  avez-vous  une  chance  raisonnable  de  mettre  fin 
au  conflit? 

Vous  devez  éviter  de  vous  engager  dans  une  gestion  de  conflit  si  vous  percevez  à 
l'avance  que  vous  n'obtiendrez  pas  de  succès.  Dès  lors  il  convient  d'adopter  un 
comportement  démissionnaire  ou  de  reproduire  le  même  schéma  à  l'encontre  de  la 
personne  qui  est  la  source  du  conflit. 

4.  Quel  processus  vous  et  l'autre  partie  choisirez  pour  résoudre  le  conflit?  Les  problèmes 
doivent-ils  être  discutés  dans  un  ordre  précis?  Quel  est  le  programme?  Il  y  a-t-il  une 
date  butoir?  Quelles  sont  les  règles  de  négociation?  Qui  convoque  et  préside  les 
réunions?  Est-ce  qu'un  accord  final  sera  signé? 

Vous  devrez  décider  du  type  de  processus  de  négociation  -  formel  (avec  un  médiateur) 
ou  informel,  par  réunion  publique,  par  évitement,  par  discussion  (à  l'aide  d'un 
facilitateur),  etc. 

5.  Est-ce  que  les  parties  veulent  négocier  sur  les  problèmes?  Est-ce  que  le  médiateur  doit 
inventer  des  propositions  spécifiques  de  compromis?  Est-ce  que  les  parties  doivent 
développer  leurs  propres  propositions  ou  travailler  ensemble  sur  un  accord  commun  et 
négocier  ensuite  section  par  section? 

Cette  étape  doit  se  faire  avec  les  deux  parties  en  présence.  Comme  dans  le  cas  de  la 
négociation,  l'écoute  de  l'autre  partie  est  le  point  important  de  cette  phase.  Il  est 
important  que  les  parties  comprennent  leurs  buts  et  leurs  besoins  réciproques  afin  de 
pouvoir  trouver  une  solution  qui  satisfasse  tout  le  monde.  Dans  la  plupart  des  cas  de 
gestion  de  conflit,  c'est  à  ce  stade  que  la  négociation  entre  en  scène.  Cependant,  ceci 
peut  se  faire  par  des  négociations  formelles  ou  informelles  suivant  la  situation  et  les 
personnes  impliquées.  Lorsque  l'on  discute  des  solutions,  il  est  primordial  que  les 
besoins  des  parties  et  les  solutions  soient  décrits  de  manière  très  concrète. 

6.  Comment  s'assurer  que  les  parties  respectent  l'accord?  Est-ce  que  les  parties  et  le 
négociateur  doivent  encore  se  rencontrer  automatiquement  après  une  certaine  durée  de 
mise  en  œuvre?  Est-ce  que  l'accord  doit  être  mis  à  jour  plus  tard  si  les  conditions 
changent? 

Quand  vous  parvenez  à  un  accord,  il  est  important  que  les  deux  parties  aient  la  même 
vision  des  résultats.  Une  manière  de  le  vérifier  est  de  se  mettre  d'accord  sur  des  actions 
à  suivre,  sur  qui  va  les  réaliser  et  d'être  très  concret  et  spécifique  avec  un  échéancier 
d'application  et  un  suivi  d'anomalies  de  non-respect  ultérieur.  Il  peut  aussi  être 
essentiel  pour  les  parties  de  vendre  l'accord  à  leurs  parties  prenantes. 
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Si  vous  négociez  avec  une  partie  avec  laquelle  vous  avez  été  ou  vous  êtes  présentement  en 
conflit,  beaucoup  d'ouvrages  proposent  de  suivre  les  six  étapes  positives  suivantes  pour 
faciliter  l'accès  à  une  solution  acceptable  (j'ai  mis  en  italique  mes  remarques  personnelles  et 
ma  vision  des  choses  relativement  à  mon  expérience  dans  la  gestion): 

1.  Adoptez  une  approche  de  résolution  de  problème  (situation  win-win). 

Cette  approche  n'est  applicable  que  lors  de  la  première  tentative  de  résolution  d'un 
problème  donné.  Au-delà  du  troisième,  quatrième,  etc...  cela  devient  ingérable  et  il 
n'existe  plus  de  bonnes  solutions. 

2.  Écoutez  l'autre  partie. 

Encore  une  fois,  cette  approche  n'est  applicable  que  lors  de  la  première  tentative  de 
résolution  d'un  problème  donné.  Au-delà  du  troisième,  quatrième,  etc...  nous  ne  nous 
savons  pas  écouté  et  il  ne  reste  plus  que  la  manifestation  orale  violente. 

3.  Posez  des  questions  pour  connaître  les  arguments  de  l'autre  partie,  clarifier  les 
problèmes,  et  vérifier  la  compréhension. 

Si  le  même  conflit  se  répète  plus  tard,  cette  étape  doit  être  sautée  est  la  situation 
clarifiée.  La  seule  solution  après  signature  du  procès-verbal  antérieur  et 
l'avertissement! 

4.  Restez  ouvert. 

Cela  n'a  de  sens  que  si  le  conflit  débute  ou  que  les  arguments  diffèrent.  Mais  une  fois 
le  procès-verbal  signé  lors  de  la  première  discussion,  il  convient  de  mettre  les  points 
sur  le  i  et  de  menacer  le  non-respect  via  un  avertissement. 

5.  Rapprochez-vous  des  uns  et  des  autres.  Le  mouvement  est  le  seul  moyen  de 
progresser. 

Ceci  peut  être  par  contre  dangereux  lors  de  conflits  répétitifs  sur  un  même  sujet.  On 
peut  même  en  arriver  aux  mains  ou  pire... 

6.  Faites  la  distinction  entre  le  problème  et  les  personnes. 

C'est  une  illusion...  70%  du  temps  les  conflits  sont  liés  à  la  personnalité,  au 
comportement  et  au  professionnalisme  des  personnes. 

Lorsque  qu'un  premier  conflit  survient  sur  un  sujet  X,  l'application  des  méthodes  ci-dessus  est 
une  première  étape.  Cependant,  si  elle  n'aboutit  à  rien  (aucune  promesse  tenue)  alors  qu'un 
procès-verbal  a  été  signé,  il  reste  à  répéter  la  même  chose  avec  la  hiérarchie  supérieure 
jusqu'au  plus  haut  rang  possible  (cela  peut  donc  durer).  Si  toujours  aucun  résultat  n'est  obtenu, 
il  ne  reste  plus  que  la  violence  verbale  et  les  avertissements  malheureusement. . . 

S'il  vous  est  demandé  d'être  un  médiateur  dans  un  conflit,  ou  si  vous  le  choisissez  vous-même 
parce  que  vous  êtes  le  directeur  du  projet,  votre  travail  (en  tant  que  partie  neutre)  sera  d'aider 
les  parties  à  résoudre  leur  conflit,  et  pas  d'essayer  de  le  résoudre  pour  elles.  Vous  pouvez 
avoir  à  rétablir  des  moyens  de  communiquer  entre  les  parties,  si  la  communication  n'existe 
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plus  entre  elles.  Il  est  primordial  que  vous  les  aidiez  à  discuter  du  problème  de  manière 
positive.  Les  accusations  doivent  être  évitées.  Faites-les  toujours  parler  de  leurs  besoins,  au 
lieu  de  ce  que  l'autre  partie  fait  mal. 

Les  tâches  spécifiques  du  médiateur  incluent  souvent: 

1 .  Établir  l'agenda  des  réunions 

2.  Présider  les  réunions 

3.  Rédiger  les  minutes 

4.  Préparer  les  premières  versions  des  accords 

5.  Rencontrer  les  parties  individuellement 

Il  est  de  votre  responsabilité  que  les  parties  s'écoutent.  Il  peut  parfois  être  bon  de  leur 
demander  de  résumer  ce  que  l'autre  partie  a  dit.  Laissez  du  temps  pour  les  silences  pendant  les 
discussions.  Ceci  aidera  les  parties  à  s'écouter.  Très  souvent,  on  n'écoute  pas  parce  qu'on  est 
occupé  à  préparer  ce  que  l'on  va  dire  quand  l'autre  partie  aura  terminé. 

Enfin,  si  vous  mettez  en  place  des  réunions  quotidiennes  ou  hebdomadaires  pour  avoir  un 
feedback  des  tensions  ou  problèmes  internes  alors  ceux  qui  ne  parlent  jamais  pendant  ces 
réunions  n'ont  plus  le  droit  de  se  plaindre  en  dehors! 

Un  aspect  important  du  rôle  de  médiateur  est  de  laisser  les  parties  trouver  leurs  propres 
solutions  sans  leur  dire  quoi  faire.  Si  elles  trouvent  leurs  propres  solutions  plutôt  que  vous  ne 
les  imposiez,  il  est  plus  probable  qu'elles  s'accordent,  et  qu'elles  pensent  que  la  solution  est 
juste. 

Enfin,  je  pense  qu'il  faut  éviter  de  se  prendre  la  tête  pour  des  sujets  qui  n'ont  souvent  que  peu 
d'importance:  le  99.999%  des  responsables  et  ressources  intervenants  dans  les  projets  ne 
laisseront  aucune  trace  dans  les  livres  d'histoire  et  personne  ne  se  rappellera  d'eux  après  5  ou  6 
générations.  Il  est  en  est  de  même  pour  le  livrable  lui-même  qui  a  peu  de  chances  de  passer 
plus  de  cinq  siècles  dans  la  mémoire  collective  ou  même  en  tant  qu'élément  matériel  visible.  Il 
vaut  donc  mieux  prendre  les  projets  et  les  conflits  qui  y  sont  associés  avec  le  sourire  et 
légèreté  en  prenant  si  possible  plaisir  à  rendre  service  à  un  mandant  (soumissionnaire)  et  à 
travailler  en  équipe  afin  de  ne  pas  se  pourrir  le  peu  de  temps  que  nous  avons  à  profiter  de 
notre  vie.  Hâve  and  take  fun! 

Il  vaut  mieux  s'entourer  de  dissidents  constructifs  prêts  à  dire  la  vérité  ou  à  poser  des 
questions  dérangeantes,  que  de  béni-oui-oui  qui  se  bornent  à  répéter  ce  que  le 
responsable  veut  entendre.  R.  Buttrick 

8.4.8. 1  Syndrome  de  Calimero 

Le  "syndrome  de  Calimero"  est  un  facteur  important  de  détérioration  des  rapports  de  travail. 
Non  seulement  il  rend  la  vie  au  travail  difficile  mais  il  a  des  implications  parfois  dramatiques 
dans  les  situations  de  burn-out. 

Le  syndrome  de  Calimero  identifie  une  personne  qui  fait  preuve  d'une  mentalité  de  victime 
(certains  disent  à  tort  -  selon  moi  -  qu'elle  est  égocentrique),  se  répand  sur  ses  problèmes  et  a 
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tendance  à  ne  voir  que  ce  qui  va  mal,  critique  facilement  (ce  qui  peut  cependant  être  très  bon 
si  c'est  constructif  et  proactif). 

Il  existe  plusieurs  sous-familles  des  syndromes  de  Calimero.  Une  sous-famille  que  je  connais 
bien  est  celle  des  individus  qui  ne  sont  jamais  satisfaits  de  ce  qu'ils  accomplissent  (ce  soi- 
disant  peut  être  positif  pour  l'entreprise  car  ils  ont  alors  des  éléments  motivés  à  faire  mieux. . . 
alors  que  beaucoup  ne  font  rien  de  plus  que  ce  qu'on  leur  demande. . .)  car  leur  travail  n'est  pas 
défini  ni  cadré  de  manière  exacte,  les  intéressés  se  surmènent  alors  et  peuvent  s'investir 
jusqu'au  bum-out. 

Pour  éviter  ce  genre  de  situations  dans  le  cadre  d'un  projet,  il  faut  savoir  définir  en  tant  que 
responsable  de  projets  des  objectifs  très  clairs,  quantifiables  et  limités  dans  les  temps  à  chaque 
ressource  et  définir  aussi  clairement  les  objectifs  de  la  direction  et  de  l'équipe  de  gestion  en 
termes  d'échéancier  (réalisables. . .  puisque  ceux-ci  ont  souvent  un  écart  de  plus  de  400%  avec 
la  réalité. . .),  de  qualité  et  d'efforts.  Évidemment,  le  problème  est  qu'un  petit  plus  du  90%  des 
responsables  de  projets  et  dirigeants  d'entreprise  n'effectuent  pas  ce  travail  de  normalisation  et 
dès  lors  l'ensemble  de  l'environnement  est  flou,  chaotique,  sans  bornes  et  donc  globalement 
indéfini.  Par  ailleurs  c'est  ce  dernier  constat  qui  amène  au  burn-out  certains  employés  dans  de 
nombreuses  entreprises  puisque  la  quasi-totalité  des  multinationales  où  je  suis  intervenu 
utilisant  la  méthode  "La  Rache"  dans  leur  travail  quotidien. . . 

Par  ailleurs  les  consultants  ou  coach  en  ressources  humaines,  ne  pouvant  pas  critiquer  les 
équipes  dirigeantes  qui  les  ont  mandatées  (ils  n'osent  pas  faute  de  perdre  leur  contrat. . .)  pour 
résoudre  les  problèmes  de  ceux  souffrants  de  syndrome  de  Calimero,  mettent  quasiment 
systématiquement  les  torts  sur  l'employé  alors  que  de  mon  expérience  le  problème  vient  d'un 
manque  de  rigueur  de  méthode  absolument  abyssal  des  responsables  de  projets  ou 
d'entreprise. 

Il  faut  aussi  signaler  le  manque  de  reconnaissance  des  instances  dirigeantes  du  travail 
accompli  qui  génère  une  démotivation  et  alors  une  tendance  à  amener  les  collaborateurs  à 
souffrir  du  syndrome  de  Calimero.  Si  un  employé  s'investit  dans  son  travail  en  apportant  de 
nouvelles  idées  qui  amènent  une  plus-value  à  l'entreprise  il  faut  le  féliciter  car  vous  avez  alors 
une  perle  rare  entre  les  mains  (99%  des  employés  travaillent  uniquement  pour  remplir  la 
marmite. . .).  Inutile  de  donner  une  augmentation  de  salaire  car  ce  n'est  souvent  pas  ce 
qu'attendent  ce  type  d'éléments.  Offrir  des  jours  de  congés  payés  leur  fera  largement  plaisir  en 
contrepartie  de  l'effort  fourni  ou  un  petit  article  de  presse  sur  l'Intranet  leur  donnera  une 
certaine  reconnaissance. 

Ce  syndrome  est  particulièrement  marqué  parmi  les  cadres  moyens.  En  diminuant  les  effectifs 
(ou  en  les  maintenant  constants. . .),  les  dirigeants  accroissent  la  charge  de  ces  cadres  sans 
augmenter  leur  efficacité  ni  leur  influence  ce  qui  amène  irrémédiablement  à  une  surcharge  de 
travail,  une  frustration,  une  diminution  de  la  qualité  et  de  l'écoute. 

Des  recherches  (dont  je  n'ai  pu  obtenir  les  sources. . .)  citées  par  plusieurs  spécialistes  en 
ressources  humaines  auraient  prouvé  que  les  équipes  et  de  travail  et  les  collaborateurs  les  plus 
heureux  étaient  ceux  qui  acceptaient  l'idée  de  renoncer  à  atteindre  un  haut  niveau  de 
performance,  de  créativité  et  de  qualité. 

Ma  réaction  par  rapport  à  ce  type  de  communication  est  la  suivante:  bridez  vos  employez  afin 
d'en  faire  des  moutons  qui  viennent  seulement  pour  faire  ce  que  vous  leur  demandez  et  vous 
verrez  que  l'innovation  dans  votre  entreprise  tombera  à  zéro  (si  l'on  suite  la  référence  des 
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spécialistes  en  ressources  humaines. . .).  Moi  aussi  je  peux  citer  des  études  faites  par  trois 
grandes  universités  américaines  qui  ont  démontré  que  les  employés  à  qui  on  en  laisse  pas  libre 
cours  à  leur  imagination  et  à  leur  créativité  perdaient  tout  esprit  d'innovation  et  de 
motivation. . .  Il  faut  donc  faire  un  choix  et  le  mieux  c'est  d'en  discuter  ouvertement  avec  les 
employés  concernés  régulièrement. 

Une  méthode  de  management  consiste  à  classer  les  salariés  selon  un  code  couleurs: 

■  Consacrer  son  énergie  à  organiser  le 
groupe  des  alliés. 

■  Mettre  en  avant  les  «  triangles  d’or  » 

Les  triangles  d’or  sont  les  alliés  qui  ont 
su  garder  un  esprit  critique  sur  le  projet 
(positionnement  :  +3;  -2  ,  +4;  -2  et  +4  ;  - 
3):  ce  sont  donc  les  plus  crédibles  pour 
convaincre  les  hésitants 

■  Consacrer  le  moins  d’énergie  et  de 
temps  possible  aux  opposants,  éviter 
le  «  syndrome  de  la  pie  ». 

■  Utiliser  les  principaux  leviers  de  la 
mobilisation  argumenter,  reformuler 
et  s’appuyer  sur  ses  alliés. 


-1  -2  -3  -4 


•  le  vert  correspondant  aux  alliés  de  la  direction,  favorables  au  changement 

•  l'orange,  aux  partenaires  potentiels 

•  le  rouge,  aux  récalcitrants 

•  le  rouge,  foncé  aux  rebelles 


8.4.9  Souffrance  au  travail 

Ne  pas  reconnaître  sa  propre  valeur  c'est  faciliter  la  réussite  des  médiocres. 

Par  le  manque  de  formation  de  haut  niveau  des  responsables  d'entreprise  et  des  gestionnaires 
de  projets,  la  souffrance  au  travail  (par  "souffrance"  il  faut  comprendre  un  "mal-être"  ou  un 
stress  envahissant  dans  le  privé)  ressentie  par  les  employés  ne  cesse  de  croître  à  cause  du 
manque  de  rigueur  général  et  de  la  demande  de  transversalité  des  compétences. 

Dans  une  société  où  l'économie  n'est  plus  au  service  de  l'homme,  mais  l'homme  au  service  de 
l'économie,  les  objectifs  de  productivité  et  les  méthodes  de  management  poussent  les  salariés 
au  bout  et  parfois  au-delà  de  leurs  limites. 

Outre  quelques  cadres  pervers  sévissant  ici  et  là  (souvent  des  cadres  qui  se  pensent 
indispensables  et  irremplaçables),  le  fond  du  problème  se  situerait  plus  dans  une  idéologie 
managériale  propagée  dans  le  monde  de  l'entreprise.  Les  salariés  étant  de  plus  en  plus  seuls  et 
assujettis  à  des  objectifs  qu'ils  ne  peuvent  pas  atteindre. 
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Une  enquête  pour  le  CNRS  (Centre  national  de  la  recherche  scientifique)  relève  que  même  si 
on  travaillait  dans  des  conditions  bien  plus  difficiles  au  20eme  siècle,  la  dégradation  profonde 
du  «vivre  ensemble»  fait  que  les  gens  sont  aujourd'hui  très  seuls  face  à  l'arbitraire. 

C'est  aussi  la  perte  de  sens  qui  donne  le  goût  de  l'enfer  au  travail.  Pour  prévenir  le  burn-out,  il 
faut  notamment  que  chacun  retrouve  son  essentiel  en  se  projetant  dans  l'avenir  et  en 
s'interrogeant  sur  ce  qui  a  constitué  sa  vie.  Retrouver  ce  qui,  dans  une  journée  de  travail, 
donne  sens  à  sa  vie  aide  à  retrouver  du  sens  à  son  travail. 

Un  bon  moyen  de  savoir  où  en  sont  les  choses  et  les  pourquoi  du  comment  est  de  faire  des 
sondages  anonymes  par  de  société  d'audit  externes  et  que  les  spécialistes  des  ressources 
humaines  appellent  des  "180°"  (le  chef  juge  de  façon  normative  ses  ressources)  ou  "360°" 
(tout  le  monde  juge  tout  le  monde). 

Les  360°  sont  d'une  redoutable  efficacité  si  utilisés  correctement! 

Enfin  indiquons  le  modèle  empirique  de  Maslow  dans  le  cadre  du  travail  professionnel:  la 
motivation  par  la  hiérarchie  des  besoins. 

Nous  avons  alors  typiquement  de  bas  en  haut  un  ensemble  de  besoins  que  le  responsable  de 
projets  et  en  particulier  (normalement...)  le  responsable  des  ressources  humaines  peut  utiliser 
pour  lors  d'entrevues  individuelles  les  ressources  du  projet  lorsqu'il  y  a  des  conflits  (car  ses 
besoins  peuvent  être  une  source  possible  de  conflits): 


Pyramide  de  Maslow 


Besoins  de  Réalisation  personnelle,  Estime  de  soi 

Fierté  du  travail  accomplit;  Sentiment  de  laisser  "quelque  chose"; 
Développement  personnel 


Besoin  de  reconnaissance 

Titre;  Statut;  Compétences  reconnues;  Responsabilité  et  Autorité;  Être 
consulté  ou  considéré  comme  un  expert _ 

Besoin  d'appartenance 

Faire  partie  d'une  entreprise,  d'une  communauté;  Être  complètement 
intégré;  Intégrer  des  groupes  de  travail,  de  réflexion;  Être  au  courant  de  ce 
qui  se  passe 


Besoins  de  sécurité 

Peu  d'incertitude  sur  l'avenir  au  moins  à  moyen  terme;  Disposer  d'une 
certaine  stabilité  CDI/CDD;  Ancienneté 


Tableau  14  Pyramide  de  Maslow 


et  se  rappeler  qu'il  existe  de  nombreuses  entreprises  connues  de  par  le  monde  où  les  employés 
se  sont  suicidés  en  laissant  une  lettre  comme  quoi  ils  avaient  un  mal  être  à  cause  d'un  manque 
de  reconnaissance  dans  leur  cadre  professionnel...! 

8.4.10  Suggestions  du  personnel 

Le  texte  qui  va  suivre  concernant  ce  petit  chapitre  est  un  copier/coller  de  quelques  parties  de 
l'excellent  livre  Processus:  les  outils  d’optimisation  de  la  performance  de  Yvon  Mougin 
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(ISBN  2708130226,  Éditions  d'Organisation)  car  simplement  le  sujet  y  est  parfaitement  traité 
et  il  n'y  a  rien  a  rajouté  (et  je  déteste  recréer  la  roue  quand  celle-ci  tourne  parfaitement!). 

L'implication  du  personnel  dans  les  suggestions  (principalement  d'amélioration)  est  un  des 
tentatives  d'amélioration  les  plus  anciennes.  Le  principe  est  simple.  Il  est  tentant  de  penser 
que,  si  chaque  collaborateur  se  mettait  à  donner  des  idées  d'amélioration,  même 
modestement,  le  nombre  produirait  une  quantité  de  suggestions  intéressantes 

Un  exemple  intéressant  citée  dans  la  livre  susmentionné  est  le  suivant: 

Quelques  chiffres  officiels  obtenus  par  l'Institut  Qualité  et  Management  qui  datent  de  1992 
(donc  près  d'un  siècle  après  l'initiative  des  USA)  sont  peu  encourageants  sauf  pour  le  Japon 
qui  a,  paraît-il,  été  longtemps  leader  en  la  matière.  En  1992  donc,  les  Japonais  obtenaient  en 
moyenne  vingt-cinq  suggestions  par  personne  et  par  an  alors  qu'en  France,  on  en  était  à  une 
moyenne  de  0.4.  Le  pourcentage  de  mise  en  oeuvre  des  idées  (c'est  important  aussi)  était  de 
87  %  au  Japon  et  de  56  %  en  France.  Les  autres  pays  occidentaux  avaient  des  performances 
sensiblement  égales  aux  françaises.  Ces  informations  ne  concernent  que  les  entreprises  qui  ont 
déclaré  avoir  mis  en  place  des  systèmes  de  suggestions  du  personnel.  Ce  qui  est  à  noter  dans 
l'enquête  est  que  les  suggestions  au  Japon  ne  sont  pas  récompensées  financièrement  alors 
qu'elles  le  sont  dans  la  plupart  des  pays  d'Europe  et  aux  États-Unis.  Il  y  a  là  matière  à 
réflexion  car  c'est  une  idée  bien  ancrée  dans  l'esprit  des  chefs  d'entreprises  qu'un  système  de 
suggestions  ne  peut  fonctionner  sans  une  carotte  financière. 

D'après  l'expérience  de  l'auteur  du  même  livre,  Quelques  personnes  malhonnêtes  glissaient 
des  suggestions  à  l'oreille  des  ouvriers  et  se  partageaient  ensuite  la  prime.  Des  rumeurs  ont 
même  couru  sur  des  défauts  mis  volontairement  dans  les  produits  ou  des  modes  opératoires 
par  les  ingénieurs  et  techniciens  des  bureaux  d'études  et  de  méthodes  pour  pouvoir  ensuite 
proposer  des  solutions  d'amélioration. 

De  plus  avec  les  primes  il  y  a  toujours  le  problème  de  "Mon  idée  était  meilleure  que  la  tienne 
( mes  idées  sont  toujours  meilleures  que  celles  des  autres )  et  ma  prime  est  moins  importante, 
ce  n'est  pas  juste,  etc.”. 

La  piste  que  je  propose  personnellement  (donc  rien  à  voir  avec  le  livre  qui  sert  de  référence 
pour  ce  petit  chapitre!)  plutôt  que  de  donner  des  primes  ou  rien  du  tout  est  de  prévoir  par 
contrat  des  pénalités  financières  sur  salaire  pour  manquement  de  professionnalisme  vis  à  vis 
de  l'activité  quotidienne. 

Enfin,  rappelons  une  notion  essentielle!  Il  convient  de  faire  des  suggestions  d'amélioration  en 
forme  de  solutions  et  non  en  forme  de  question! 


8.4.11  Standardisation  entre  les  ressources 


Un  point  important  dans  un  projet  est  que  les  ressources  se  mettent  d'accord  pour  travailler, 
organiser  les  données/outils/documents  d'une  manière  identique.  Nous  rappelons  encore  une 
fois  à  cet  effet  la  proposition  de  la  mise  en  œuvre  la  méthode  5S  que  nous  avons  déjà 
mentionné  à  maintes  reprises. 
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2m  iîiliijîjj2ii 


1  Diminuez  avant 
d’organiser. 

Les  piles  doivent 
disparaître.  Ne  pas  trier  ni 
empiler  mais  décider: 
jeter,  déléguer,  régler  ou 
classer. 

2  Apprenez  à  trier 
rapidement. 

Ne  prenez  qu'une  seule 
fois  en  main  et  ne  le 
remettez  pas  sur  la  pile. 

3  Débarrassez  votre 
table  de  travail. 

N'y  déposez  que  ce 
dont  vous  avez  besoin 
pour  votre  tâche 
immédiate.  Quand  vous 


l'avez  terminée, 
redébarassez-la. 


4  Aménager  une  piste 
d’atterrissage. 

Tout  ce  qui  arrive  sur 
votre  table  doit  atterrir  à  sa 
place  et  pas  ailleurs  ! 

5  Créez  des  endroits 
privilégiés 

Ce  que  vous  utilisez 
tout  le  temps  doit  se  trouve 
à  portée  de  main. 

6  Mettez  tout  par  écrit 

Mais  pas  n'importe 
comment.  Les  rendez- 


vous  doivent  figurer  dans 
l'agenda  et  non  sur  des 
bouts  de  papier,  les 
numéros  de  téléphone  sont 
notés  dans  un  répertoire, 
les  notes  non  classables 
doivent  être  informatisées 
au  propre.  Le  savoir  de 
l'entreprise  doit  être  écrit 
en  cas  d'accident  ou  de 
départ! 

7  Réduisez  la 
décoration  à 
l’essentiel. 

Sans  être  nu,  votre  bureau 
ne  doit  pas  faire 
concurrence  à  un  magasin 
de  souvenirs. 


8 Accordez-vous  du 
calme. 

Si  l'environnement 
n'est  pas  propice  à  une 
bonne  concentration  ou  si 
vous  cherchez  les  calme, 
allez  dans  un  bureau 
monoplace  et  fermez-en  la 
porte. 

9 Faites  de  l’ordre. 

Tous  les  jours  sur  votre 
bureau.  Et  au  moins 
une  fois  par  semaine  dans 
votre  porte-documents,  les 
boîtes  à  cartes  de  visite, 
documents  électroniques, 
e-mails,  etc. 


Il  en  va  de  même  pour  la  communication  entre  les  ressources.  Effectivement  à  l'époque  du  e- 
mail  le  constat  des  spécialistes  est  que  l'usage  en  est  catastrophique  en  termes  de 
centralisation,  de  standardisation  et  de  contrôle  d'accès.  Un  très  bon  outil  informatique  pour 
gérer  tout  ce  qui  est  relatif  à  la  communication  dans  un  projet  est  Microsoft  Office 
SharePoint. 
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8.4.12  Matrice  des  responsabilités 

Il  faut  savoir  que  la  grande  majorité  des  individus  n'agissent  que  si: 

•  ils  ont  envie  d'agir  (motivation) 

•  ils  savent  comment  agir  (formation/compétence) 

•  ils  ont  la  possibilité  d'agir  (responsabilité/délégation) 


DANS  CHAQUE  ÉQUIPE  DE  PROJET 

(ON  A  TOUS  CONNU  UN  JOUR) 


Les  premier  point  est  un  problème  qui  doit  être  identifié  à  l'embauche  (celles-ci  étant  souvent 
bâclées  en  moins  de  deux  heures  et  sans  tests/examens  d'entrée).  Le  point  second  pose 
rarement  problème  puisque  la  majorité  des  entreprises  et  en  particulier  les  multinationales  ont 
a  des  postes  beaucoup  de  gens  qui  n'ont  pas  les  compétences  normalement  pour  en  assumer  la 
responsabilité  et  dans  le  chaos  général  cela  ne  se  remarque  pas... 

Le  troisième  point  par  contre  est  assez  critique  dans  la  gestion  de  projets  et  est  parfois  source 
de  conflits.  Nous  allons  donc  voir  une  technique  empirique  possible  permettant  d'y  remédier 
outre  celle  des  4  niveaux  de  délégation  (4D)  qui  a  l'avantage  d'être  simple  à  mettre  en  place. 

La  matrice  RACI  ou  sa  variante  RASCI  (aussi  connu  sous  le  nom  de  Responsability 
Assignement  Matrix  (RAM))  permet  de  définir  simplement  les  rôles  et  responsabilités  dans 
un  service  ou  sur  un  projet.  On  trouve  la  définition  de  RACI  dans  le  PMBok  (Project 
Management  Body  of  Knowledge)  du  PMI  (Project  Management  Institute). 

L'acronyme  RACI  signifie: 

•  R:  Responsible:  Réalise:  Réalise  l'activité. 

•  A:  Accountable:  Autorité:  A  l'autorité  pour  approuver  le  travail  de  R. 

•  C:  Consulted:  Consulté:  Est  consulté  par  R. 

•  I:  Informed:  Informé:  Est  uniquement  informé  des  travaux  de  R. 

L'acronyme  RASCI  rajoute  le  rôle  suivant  au  RACI: 
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S:  Supportive:  En  support:  Apporte  des  ressources  supplémentaires  pour  conduire  le 
travail  de  R. 


La  confusion  peut  venir  des  rôles  R  et  A  qui  sont  souvent  inversés  dans  certaines  traductions 
françaises  car  le  terme  Responsible  n'est  pas  équivalent  de  Responsable  en  français  et  le  terme 
Accountable  est  difficile  à  traduire.  A  ne  doit  pas  être  associé  à  Approbateur  car  le  terme  peut 
donner  lieu  à  des  confusions. 


La  matrice  RACI  ou  RASCI  présente  des  activités  en  ligne  et  des  rôles  en  colonne  comme 
dans  l'exemple  ci-dessous.  Dans  chaque  cellule  du  tableau,  on  indique  la  responsabilité  du 
rôle  pour  l'activité  en  utilisant  les  lettres  du  RACI  ou  du  RASCI.  Pour  plus  de  pérennité,  il  est 
conseillé  d'utiliser  des  libellés  génériques  de  fonction  pour  qualifier  les  rôles  plutôt  que  des 
noms  de  personnes: 


Le  RACI  peut  être  utilisé  pour  établir  les  responsabilités  dans  un  projet,  une  DSI,  une 
entreprise.  Dans  un  modèle  de  document,  il  peut  aussi  indiquer  qui  doit  rédiger  (  R  )  ou 
valider  (  C  )  telle  ou  telle  partie.  Il  n'y  a  qu'une  seule  personne  qui  valide  l'ensemble  du 
document  (  A  )  par  définition.  Dans  tous  les  cas,  le  RACI  est  l'outil  idéal  pour  clarifier  "qui 
fait  quoi". 
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Un  pouvoir  de  décision 


Des  Objectifs 


Des  Moyens  cohérents 
avec  les  objectifs 


t 


Est 

Responsable 
celui  qui  a: 


Le  droit  à  l'erreur  * 


La  capacité  d’assumer  les 
conséquences  de  ces 
décisions 


Un  domaine  d'action 
défini 


*Mais  si  un  responsable  commet  trop  d'erreurs,  c'est  une  erreur  de  l'avoir  désigné  à  ce  poste. 


8.4.13  Rencontres/Réunions 

Le  responsable  du  projet  organise  souvent  les  rencontres  d'équipes,  du  CoP  (Comité  de 
Projet),  de  l'AQ  (Assurance  Qualité)  et  autres  groupes...  pour  stimuler  les  relations 
interpersonnelles  d'une  équipe  et  pour  renforcer  les  prévisions,  les  rôles  et  les  obligations  des 
membres  de  l’équipe  en  considérant  les  objectifs  du  projet.  Il  est  par  ailleurs  souvent  accepté 
comme  normal  que  le  responsable  de  projets  passe  70%  de  son  temps  en  réunion. 

Des  exemples  de  réunions  types  sont  (ne  pas  oublier  de  les  inclure  dans  la  planification  du 
projet...!): 

1.  Définition  du  cahier  des  charges  avec  les  mandants21 

2.  La  formation  de  l'équipe  (Forming,  Storming,  Norming,. . .) 

3.  Kick-OffouGo/NoGo 

4.  Validation  de  fin  de  chaque  phase  (avec  les  clients) 

5.  Résolution/anticipation  de  problèmes 

6.  Revues  d'avancement 

7.  Fin  de  projet 


21  Lorsque  celle-ci  est  sous  forme  accélérée  et  hyper  simplifiée  nous  parlons  alors  en  conformité  avec  le  BABOK 
de  JRPS  pour  "Joint  Requirements  Planning  Session". 
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et  bien  d'autres. . . 


A  ce  titre,  il  est  important  d'inclure  dans  la  planification  du  projet  des  réunions  à  l'avance, 
régulièrement  et  facturées  en  tant  que  séances  de  conseils. 

Ce  serait  un  choix  judicieux  pour  le  déroulement  des  rencontres  de  suivre  une  routine 
constante  pour  maximiser  ses  effets.  Il  est  conseillé  de  considérer  les  facteurs  suivants  avant 
que  la  rencontre  prenne  place  : 

1 .  Déterminer  si  la  rencontre  est  absolument  nécessaire 

2.  Déterminer  le  but  de  la  rencontre 

3.  Déterminer  les  participants  de  la  rencontre 

4.  Définir  le  facilitateur  de  la  rencontre  (qui  vérifie  que  tout  le  monde  écoute,  valide  et 
assure  le  consensus) 

5.  Distribuer  un  agenda  de  la  rencontre  au  moins  une  semaine  à  l'avance 

6.  Préparer  les  média  (les  transparents,  les  prospectus,  etc) 

7.  Faire  les  arrangements  pour  la  salle  de  rencontre 

8.  Faire  en  sorte  que  la  rencontre  soit  périodique  (chaque  jeudi  ou  autre) 

9.  Qu'elle  dure  une  demi-journée  afin  que  les  intervenants  aient  le  temps  de  discuter  et  de 
ne  pas  penser  à  autre  chose  qu'ils  ont  à  faire  tout  de  suite  avant  ou  tout  de  suite  après 
la  réunion. 


10.  Trouver  un  espace  de  réunion  où  chacun  peut  se  mouvoir  à  son  aise  car  dans  un  espace 
restreint,  la  pensée  est  restreinte. 

Pendant  la  rencontre  il  faut  maintenir  un  format  constant  et  essayer  de  suivre  les  suggestions 
suivantes: 


1.  Commencer  la  rencontre  à  l'heure  et  la  gérer  comme  un  mini-projet  (identifier  les 
sujets,  planifier,  réaliser,  clore) 

2.  Nommer  un  membre  de  l'équipe  pour  prendre  des  notes  de  la  rencontre 

3.  Inviter  les  membres  de  l'équipe  à  se  présenter  ou  à  se  représenter 

4.  Revenir  sur  les  points  de  la  dernière  rencontre  (comparer  au  PV) 

5.  Réviser  le  programme  et  les  objectifs  de  la  rencontre 

6.  Faciliter  la  rencontre  sans  la  dominer 


22  II  est  conseillé  aux  personnes  qui  ne  sont  pas  habituées  à  gérer  des  projets,  à  suivre  une  formation  en 
techniques  de  présentations. 
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7.  Renvoyer  les  personnes  qui  ne  sont  plus  concernées  à  partir  d'un  certain  moment  de  la 
réunion 

8.  Résumer  les  résultats  de  la  rencontre  avec  un  MindMap  ou  la  suivre  avec  un  MindMap 

9.  Essayer  de  terminer  la  rencontre  à  l'heure 

10.  Évaluer  le  déroulement  de  la  rencontre 

1 1 .  Publier  les  résultats  de  la  rencontre  dans  les  24  heures  qui  suit  la  rencontre  (PV  : 
procès-verbal).  Le  document  sommaire  devrait  être  concis  et  ne  devrait  pas  dépasser 
une  page. 

Il  est  aussi  suggéré  de  fournir  un  code  de  conduite  lors  de  la  rencontre  de  l'équipe  pour  que 
tout  le  monde  comprenne  les  comportements  acceptables.  La  figure  ci-dessous  montre  un 
exemple  d'un  code  de  conduite  utilisée  par  les  coordinateurs  de  projets. 


RENCONTRE  D’ÉQUIPE 


C  o  rporation  Nouveau  Genre 


CODE  DE  CONDUITE 

d^S’en  tenir  au  sujet  abordé, 

S^Arriver  à  temps  et  terminer  à  temps. 

S^Une  personne  prends  la  parole  à  la  fois. 

S^Tous  ont  la  responsabilité  cl- arriver  a  temps  et  de 
participer.  Soyez  préparés. 

K^Soyez  francs,  honnêtes  et  sincères. 

S^Elimiuez  les  commentaires  sarcastiques  et 
cyniques. 

IS^Le  ton  général  de  la  rencontre  sera  positif. 

Si^Éli minez  les  pensées  négatives. 

[>^Faites  de  la  critique  constructive 

C^Portez  attention.  Essayez  de  comprendre,  puis 
faites  vous  comprendre. 

Pas  de  rumeurs. 

E^Les  idées  appartiennent  au  groupe  et  non  à 
l’individu, 

y^Féquipe  parle  avec  une  voix  après  que  la  décision 
est  faite.  L’unité  est  très  importante. 

[>^Renforcez  le  comportement  positif. 

[^Gardez  votre  Calme.  Si  vous  le  perdez,  vous  avez 
tord,  personne  d’autre. _ 


En  ce  qui  concerne  le  modèle  de  PV,  il  doit  être  propre  aux  besoins  et  aux  niveaux  de  détails 
de  l’entreprise.  Il  ne  faut  pas  oublier  que  fréquemment  les  employés  n’ont  pas  beaucoup  de 
temps  pour  lire  de  la  documentation  alors  évitez  de  faire  des  PV  avec  trop  de  texte:  soyez 
brefs  et  concis. 

Remarque :  Dans  le  cas  de  la  méthode  agile  (scrum),  chaque  journée  de  travail  commence  par 
une  réunion  de  15  minutes  maximum  appelée  mêlée  quotidienne  (Daily  Scrum).  Seuls 
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l'équipe,  le  directeur  de  produit  et  le  Sérum  Master  peuvent  parler,  tous  les  autres  peuvent 
écouter  mais  pas  intervenir  (leur  présence  n'est  pas  obligatoire).  A  tour  de  rôle,  chaque 
membre  répond  à  3  questions:  Qu'est-ce  que  j'ai  fait  hier?  Qu'est-ce  que  je  compte  faire 
aujourd'hui?  Quelles  sont  les  difficultés  que  je  rencontre? 

Enfin,  la  première  réunion  avec  le  mandant  (soumissionnaire)  est  cruciale.  Il  faut  être  préparé 
et  montré  qu'on  à  l'habitude  de  gérer  des  projets  en  ayant  une  liste  de  questions  et  des 
processus  établis  à  l'avance! 

N'oubliez  pas  non  plus!  Plusieurs  têtes  valent  souvent  mieux  qu'une  (mais  pas  toujours!)  donc 
les  réunions  ne  sont  pas  inutiles! 

8.4.13.1  Types  de  participants 

Dans  une  réunion  il  est  relativement  facile  de  profiler  les  participants  car  il  y  a  certains 
schémas  assez  classiques 

-  Les  participants  imposants:  Ils  exercent  une  influence  naturellement  excessive  dans  un 
groupe,  souvent  parce  qu'ils  sont  de  rang  plus  élevé  dans  l'entreprise  (à  juste  titre  ou  pas. . .)  ou 
parce  qu'ils  ont  des  connaissances  techniques  très  pointues.  Le  rôle  de  l'orateur  est  donc  de 
faire  en  sorte  de  trouver  le  juste  milieu  entre  la  présence  d'experts  utiles  au  groupe  et  la 
possible  domination  exercée  par  ses  derniers  (leur  rappeler  parfois  qu'il  n'existe  pas  de 
domaine  sacré. . .).  Le  mieux  est  peut-être  de  les  écouter  et  de  leur  proposer  suite  à  un  tour  de 
table  avec  les  autres  participantes  de  mettre  en  place  des  actions  d'amélioration  documentées 
ou  de  formation  pour  l'équipe  de  projet  tout  en  restant  conforme  aux  processus  de  l'entreprise. 

-  Les  participants  dominateurs:  Ils  aiment  bien  s'entendre  parler,  et  donnent  rarement 
l'opportunité  aux  autres  de  contribuer.  Ils  dominent  la  réunion  par  des  interventions 
prolongées  avec  des  anecdotes  hors  sujet  ou  à  un  niveau  intellectuel  qui  ne  dépasse  guère 
l'école  obligatoire  et  qui  ne  font  que  très  rarement  avancer  les  problèmes  (souvent  ce  sont  des 
gens  qui  manquent  de  compétences  pointues).  Le  mieux  est  peut-être  de  les  demander 
d'approfondir  plus  en  détail  le  sujet  afin  qu'ils  se  rendent  compte  eux-mêmes  soit  qu'ils  sont 
hors  contexte  ou  incompétents.  Si  vraiment  ils  ne  sont  pas  possible  à  gérer,  leur  rappeler  qu'il 
y  a  un  droit  de  parole  équilibre  entre  chaque  participant  et  qu'ils  ont  utilisé  le  leur. 

-  Les  participants  hésitants:  Ils  ont  peur  à  chaque  fois  de  dire  une  bêtise  (ce  qui  peut 
cependant  être  vrai).  La  seule  manière  de  les  faire  participer  c'est  de  leur  poser  des  questions 
ouvertes  ou  fermées  et  si  jamais  de  tourner  leurs  propositions  (qui  peuvent  donc  vraiment  être 
parfois  systématiquement  mauvaises)  en  des  suggestions  constructives  et  pertinentes  (l'orateur 
de  la  réunion  doit  alors  être  très  à  l'aise  et  lui -même  maîtriser  de  très  larges  sujets).  Si  jamais 
le  participant  n'est  pas  récupérable,  lui  poser  uniquement  des  questions  fermées  afin  d'éviter 
de  lui  faire  développer  les  sujets. 

-  Les  participants  en  désaccord:  Il  peut  arriver  qu'il  y  ait  un  très  fort  désaccord  entre 
l'orateur  et  les  participants.  Une  stratégie  qui  fonctionnement  relativement  bien  c'est  que 
l'orateur  s'excuse  (sous-entendu  de  son  ignorance  et  de  son  incompétence  que  ce  soit  honnête 
ou  pas!)  et  demande  une  explication  approfondie  et  argumentée  des  faits  qui  sont  à  l'origine 
de  l'opposition. 
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8.4.14  Congés  Maladie 

Voilà  un  sujet  sensible  pour  lequel  le  responsable  de  projet  doit  avoir  une  culture  générale 
minimale  en  ce  qui  concerne  au  moins  les  lecteurs  majoritaires  du  présent  document:  les 
droits  en  ce  qui  concerne  les  congés  maladie  en  Suisse  tel  que  édictés  en  2010.  Pour  les  autres 
pays  il  est  recommandé  que  le  responsable  de  projet  s'adresse  aux  responsable  RH  de  son 
entreprise  pour  avoir  au  moins  connaissance  de  ce  points  là  pour  avoir  un  minimum  de 
crédibilité  en  cas  de  discussion  conflictuelles  avec  ses  ressources. 

Les  textes  ci-dessous  ont  été  repris  du  magazine  l'Illustré  42/10,  page  96. 

Paiement  du  salaire  en  cas  de  maladie  de  la  ressource. 

Il  faut  savoir  que  l'assurance  perte  de  gain,  au  contraire  de  l'assurance  maladie,  n'est  pas 
obligatoire.  C'est  dire  qu'une  entreprise  n'est  pas  obligée  de  contracter  une  assurance  perte  de 
gain  pour  ses  employés.  Dans  ce  cas,  l'employeur  prend  le  risque  maladie  à  sa  charge,  car  le 
Code  des  obligations  prévoit  tout  de  même  dans  l'article  324a  que  «si  le  travailleur  est 
empêché  de  travailler  sans  faute  de  sa  part  pour  des  causes  inhérentes  à  sa  personne  (...) 
l'employeur  lui  verse  le  salaire  pour  un  temps  limité».  La  durée  n'est  pas  précisée  dans  la  loi, 
mais  la  jurisprudence  se  base  sur  l'échelle  dite  de  Berne  pour  définir  le  laps  de  temps  pendant 
lequel  il  est  tenu  de  lui  verser  un  salaire.  Soit  de  trois  semaines  pendant  la  première  année  de 
service,  deux  mois  dès  la  troisième  année,  à  dix  mois  dès  la  quarantième  année  (voir  tableau 
ci-contre).  « Ce  laps  de  temps  est  évidemment  cumulatif,  explique  Célia  Borlat,  juriste  au 
syndicat  U  nia.  Si  vous  êtes  malade  plusieurs  fois  dans  la  même  année,  le  compte  ne  reprend 
pas  à  zéro,  mais  les  jours  d'absence  s'accumulent.  L'employeur  est  tenu  de  vous  les  payer 
jusqu'à  concurrence  du  barème  prévu  dans  l'échelle  de  Berne.» 

Toutefois,  une  majorité  d'entreprises  ont  conclu  un  contrat  d'assurance  perte  de  gain.  Celui-ci 
est  régi  selon  deux  lois,  soit  la  loi  sur  l'assurance  maladie  (LAMaL),  soit  selon  la  loi  sur  les 
contrats  d'assurance  (LCA).  Selon  la  LAMal,  vous  avez  droit,  en  cas  de  maladie,  au  maximum 
à  720  jours  payés  à  80%  sur  900  jours.  Selon  la  LCA,  le  contrat  peut  être  plus  flexible. 
Toutefois,  la  loi  prévoit  que  la  durée  durant  laquelle  le  salaire  est  dû  doit  être  au  moins 
équivalente  aux  règles  de  l'échelle  de  Berne.  La  jurisprudence  des  tribunaux  a  ainsi  estimé 
que  l'équivalence  se  situait  à  720  jours  à  80%.  En  général,  la  majorité  des  contrats  selon  la 
LCA  prévoient  une  durée  de  730  jours  payés  à  80%  par  cas  de  maladie. 

Absence  sans  certificat  maladie 

Légalement,  rien  n'est  prévu.  C'est  dire  que  l'employeur  pourrait  vous  demander  un  certificat 
médical  dès  le  premier  jour  d'absence.  Il  doit  cependant  le  demander  par  écrit.  Dans  la 
pratique,  les  délais  sont  divers.  Cela  dépend  des  employeurs.  A  la  Confédération,  par 
exemple,  il  est  plus  long,  puisque  vous  ne  devez  fournir  un  certificat  médical  qu'à  partir  du 
sixième  jour  d'absence.  En  revanche,  certaines  conventions  collectives,  notamment  dans  le 
domaine  du  bâtiment,  sont  moins  larges  et  exigent  un  certificat  dès  le  deuxième  jour 
d'absence.  «En  fait,  cela  dépend  souvent  du  contrat  d'assurance  qu'a  signé  l'employeur.  Si, 
par  exemple,  l'assurance  couvre  le  risque  maladie  dès  le  premier  ou  le  deuxième  jour 
d'absence,  celle-ci  exigera  généralement  immédiatement  un  certificat»,  précise 
Jean-Marc  Rossier,  responsable  du  personnel  d'Unia  Vaud  et  ancien  secrétaire  syndical.  Reste 
que  la  plupart  des  employeurs  prennent  généralement  le  risque  maladie  à  leur  charge  durant 
les  trois,  sept,  voire  trente  premiers  jours,  et  s'assurent  essentiellement  pour  les  cas  de  maladie 
de  longue  durée. 
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Jour  de  congé  pour  s'occuper  des  enfants  malade 

Légalement  e  n'est  pas  un,  mais  jusqu'à  trois  jours  qu'un  employé  peut  prendre  dans  le  cas  de 
la  maladie  de  l'un  de  ses  enfants.  «L'employeur  doit,  sur  présentation  d'un  certificat  médical, 
donner  congé  aux  travailleuses  et  travailleurs  ayant  des  responsabilités  familiales  pour  le 
temps  nécessaire  à  la  garde  d'un  enfant  malade  jusqu'à  concurrence  de  trois  jours»,  stipule 
ainsi  l'article  36  alinéa  3  de  la  Loi  sur  le  travail.  Toutefois,  une  règle  de  bonne  foi  est  d'usage. 
Le  père  ou  la  mère  doit  en  effet  reprendre  le  travail  dès  que  la  garde  de  l'enfant  est  organisée, 
même  si  le  délai  de  trois  jours  n'est  pas  complètement  écoulé. 

Licenciement  pendant  la  maladie 

En  fait,  vous  ne  pouvez  pas  licencier  en  cas  de  maladie  pendant  un  temps  de  protection  défini 
par  la  loi.  Soit  trente  jours  durant  la  première  année  de  service,  nonante  jours  de  la  deuxième  à 
la  cinquième  année  et  180  jours  dès  la  sixième  année.  L'employeur  ne  peut,  pendant  ces  laps 
de  temps,  pas  vous  signifier  votre  congé.  En  revanche,  il  peut  le  faire  dès  la  reprise  de  votre 
activité  ou  vous  donner  votre  congé  à  la  fin  de  la  période  de  protection,  même  si  vous  êtes 
encore  malade.  Le  délai  de  résiliation  de  votre  contrat  court  alors  à  partir  de  la  date  de  la  fin 
de  la  période  de  protection. 

Causes  exactes  de  la  maladie 

Ni  le  responsable  de  projet,  ni  le  responsable  des  ressources  humaines,  ni  le  directeur  de 
l'entreprise  n'a  le  droit  de  demander  à  un  de  ses  employés  les  causes  exactes  de  votre  maladie. 

8.4.15  L'espace  blanc 

L'écart  entre  les  ressources  engagées  et  les  ressources  totales  dont  vous  disposez  est 
fréquemment  appelé  "l'espace-blanc".  C'est  un  élément  essentiel  pour  la  santé  d'une  entreprise 
au  quotidien.  Si  Vous  vous  n'en  avez  pas  du  tout  entre  le  court  et  le  moyen  terme,  vous  êtes 
paralysé:  vous  n'avez  personne  de  disponible  pour  changer  l'entreprise,  répondre  à  de 
nouvelles  menaces  ou  exploiter  de  nouvelles  opportunités  avec  qualité  -  à  moins  de  retirer 
certaines  personnes  d'un  travail  dans  lequel  elles  se  sont  déjà  engagées  ou  de  leur  faire  ce 
travail  de  manière  souvent  médiocre  dans  le  cadre  d'heures  supplémentaires  ce  qui  risquer  de 
faire  perdre  des  contrats. 

L'espace  blanc  donne  donc  les  ressources  pour  effectuer  le  changement  à  venir  (veille 
technologique,  anticipation,  gestion  des  inattendus  et  autres). 

De  mon  expérience  personnelle,  toute  entreprise  qui  n'avait  pas  d'espace  blanc  avait  soit  un 
turnover  phénoménal,  soit  une  perte  de  motivation  conséquente  de  ses  collaborateurs,  soit 
perdait  quelques  mandats  sous  l'effet  du  stress  et  du  manque  de  qualité  des  démarches  de  ses 
collaborateurs  sous  le  coup  de  dizaines  d'heures  supplémentaires  par  semaine. 

Évidemment,  afin  de  contrôler  ou  mettre  en  place  des  espaces  blancs,  il  faut  mettre  en  place 
un  système  de  suivi  du  temps  centralisé.  Ceci  principalement  afin  d'améliorer  la  gestion  du 
temps  qui  dans  la  majorité  des  entreprises  (on  ne  doit  pas  être  loin  du  99%...)  est 
catastrophique  soit  pour  éviter  des  conflits  entre  ce  qui  est  pensé  être  fait  et  ce  qui  a  été  fait. 

Ainsi,  le  concept  des  feuilles  de  temps  (centralisée  via  un  ERP  par  exemple)  même  mal  perçu 
par  certains  employés  méfiants  reste  un  bon  outil  dans  le  sens  que  c'est  meilleure  que  rien. 
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Personnellement  je  recommande  au  lieu  de  cet  outil  que  je  trouve  déplacé  et  inutile 
statistiquement  parlant  de  faire  en  sorte  que  toute  l'entreprise  travaille  dans  l'optique  de  la 
gestion  de  projet  (cela  évite  la  double  saisie  de  la  feuille  de  temps).  C'est-à-dire  que  chaque 
tâche  soit  notée,  assignée  à  un  projet,  à  un  initiateur  avec  un  temps  estimé  et  temps  réel  ainsi 
qu'une  date  début  demandé,  une  priorité  et  une  échéance  (bien  évidemment  dans  un  système 
informatique  centralité  et  non  pas  dans  un  tableur!). 

Grâce  à  ce  type  d'outil  j'arrive  facilement  à  montrer  au  managers  et  employés  les  problèmes 
d'estimation  du  temps  (souvent  sous-évalués  par  les  responsables  qui  n'ont  pas  la 
connaissance  du  concept  de  qualité  faute  de  formation)  et  il  est  facile  d'avoir  une  très  bonne 
estimation  du  travail  exact  de  chaque  employé  par  projet  ou  par  département. 

Un  autre  point  très  utile  d'une  optique  "projet"  de  la  gestion  du  temps  (in  extenso  donc  de 
toutes  les  tâches)  est  que  tout  employé  peut  potentiellement  (en  fonction  de  ses  autorisations) 
savoir  ce  que  chacun  fait  à  tout  moment  de  la  journée  en  temps  réel.  Ce  qui  n'est 
malheureusement  pas  le  cas  avec  la  vieille  méthode  des  feuilles  de  temps  remplies  soit  en  fin 
de  mois,  soit  en  fin  de  journée.  De  plus,  cette  vieille  méthode  ne  permet  de  corriger  des 
imprévus  qu'avec  des  retards  corresponds  à  la  période  de  saisie  choisie  alors  qu'avec  le 
système  des  tâches  nous  avons  souvent  un  état  de  lieux  de  l'entreprise  à  la  minute  près  et  donc 
de  faibles  écarts  entre  le  prévisionnel  et  le  réel! 

Remarque:  Utiliser  un  logiciel  du  type  MS  Office  Outlook  ou  MS  Project  ou  tout  autre  pour 
gérer  les  tâches  et  le  temps  de  façon  détaillée  est  une  très  très  mauvaise  initiative.  Il  vaut 
mieux  s'orienter  vers  des  outils  web  comme  MS  Office  SharePoint  Services  (gratuit!)  et  ses 
listes  de  gestion  des  tâches  intégrées  qui  est  un  relativement  bon  outil  pour  commencer.  Sinon 
pour  aller  un  cran  au-dessus  il  faudra  se  reporter  à  MS  Project  Server  qui  reste  l'outil  de 
référence  mondiale  à  ma  connaissance  pour  ce  type  d'objectif  puisqu'il  gère  les  conflits,  les 
approbations  ainsi  que  les  priorités. 

Une  solution  élégante  que  m'a  montré  une  fois  un  client  pour  avoir  un  suivi  du  travail  précis 
de  ses  collaborateurs  sans  avoir  à  leur  demander  de  passer  10  à  15  minutes  par  jour  (temps 
estimé  par  le  client)  à  faire  de  la  saisie  (ce  qui  emm. . .  tout  le  monde  il  faut  le  dire 
honnêtement  et  génère  des  coûts  financiers  indirects)  est: 

1.  D'engager  un  opérateur/rice  de  saisie  avec  un  numéro  de  téléphone  fixe  et  un  système 
de  messagerie  vocal 

2.  Le  numéro  de  téléphone  de  l'opérateur  est  communiqué  à  tous  les  employés  et  stockés 
dans  leur  téléphone  portable  d'entreprise 

3.  Les  employé  sont  tous  munis  d'une  oreillette  bluetooth  et  utilisent  Siri  pour  lancer 
l'appel  sans  avoir  à  prendre  l'appareil  dans  les  mains 

4.  Le  contact  établi,  les  employés  communiquent  à  la  messagerie  vocale  la  tâche  à  saisir 
dans  le  système 

5.  L'opérateur/opératrice  saisi  une  tâche  environ  toutes  les  10-20  secondes 

Il  a  put  être  démontré  que  le  coût  salariale  de  l'opérateur/rice  de  saisie  permettait  des 
économies  considérable  à  l'échelle  de  l'entreprise  (diminution  d'environ  60%  des  coûts). 
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8.5  Communication 

La  communication  dans  les  projets  était  très  difficile  avant  l'internet  et  le  téléphone  mobile. 
Aujourd'hui  ce  problème  devrait  être  résolu  avec  les  avancées  technologiques  existantes  mais 
un  autre  effet  est  venu  annuler  l'avantage:  énormément  d'entreprises  considèrent  que  le 
responsable  de  projet  doit  s'occuper  de  la  planification,  de  la  finance,  des  contrats,  de  la 
logistique,  des  ressources,  de  la  communication,  etc.  (problème  de  l'organisation  matricielle 
qui  mettent  des  incompétents  à  toutes  les  fonctions  par  définition... 0- 

La  grande  majorité  du  temps  j'observe  que  les  responsables  de  projets  (et  pas  que!)  ont  entre 
15  et  20  activités  dans  leur  cahier  des  charges  au  quotidien.  Ce  qui  fait  pour  une  journée  de  10 
heures  type,  un  responsable  de  projets  a  à  peine  entre  30  et  40  minutes  à  consacrer  à  chaque 
activité.  On  comprend  alors  tout  de  suite  mieux  le  taux  d'échecs  des  projets  quand  on  sait 
qu'un  pilier  fondamental  (voire  LE  pilier  fondamental)  d'une  bonne  gestion  de  projets  est  la 
communication!  Par  ailleurs,  des  méthodes  comme  Agile  (et  implicitement  Scrum  et  autres  du 
même  genre)  donnent  une  place  importante  à  de  nombreuses  petites  réunions. 

Si  le  responsable  de  projet  est  soutenu  par  un  responsable  de  la  communication  du  projet  qui 
s'occupe  de  récolter  les  informations  et  de  les  synthétiser  alors  il  peut  pour  tout  projet  se  poser 
les  cinq  questions  minimales  suivantes: 

1.  Communiquer  vers  qui? 

Utilisateurs  finaux,  équipe  projet,  direction  du  projet,  clients.  Attention  à  réduire  le 
nombre  de  cibles  sinon  quoi  vous  allez  passer  vos  journées  à  faire  de  la 
communication.  Sinon  déléguez  cette  tâche  à  un  spécialiste  de  la  communication  de 
projets  (project  community  manager). 

Comme  le  signale  le  PMBOK,  et  comme  nous  l'avons  démontré  dans  le  cours  de 
théorie  des  graphes,  si  nous  considérons  le  réseau  de  communication  comme  un 
graphe  complet  (toutes  les  arêtes  possibles  pouvant  relier  les  sommets  deux  à  deux 
sont  présentes)  avec  n  sommets: 
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alors  le  nombre  de  canaux  de  communication  possibles  est  donné  par:  n(n  — 1)/2 


(donc  proportionnel  au  carré  du  nombre  d'intervenants).  Si  par  exemple  vous  gérez  un 
projet  avec  10  intervenants  (correspondant  à  n ),  il  y  a  donc  45  canaux  de 
communication  (e-mail  ou  téléphone)  possibles.  D'où  l'importance  en  gestion  de  projet 
de  définir  des  règles  de  communication  claires  (sous  forme  d'un  graphe)  si  l'on  ne  veut 
pas  être  noyé  par  les  e-mails  ou  les  téléphones  inutilement. 


2.  Communiquer  pourquoi? 

Pour  fédérer,  mobiliser  l'équipe  projet,  associer  les  utilisateurs  finaux  et  informer  les 
mandants  de  l'avancement. 


3.  Communiquer  quoi? 

Les  objectifs,  les  enjeux,  les  risques,  les  résultats  intermédiaires,  l'organisation,  le 
planning,  l'avancement...  Attention  aux  informations  utlra  confidentielles  qui  doivent 
être  cryptées  ou  ne  pas  passer  par  un  format  électronique  quel  qu'il  soit. 

Par  ailleurs  le  communiquer  quoi  est  bien  résumé  par  le  schéma  suivant  entre  l'orateur 
(expéditeur)  et  auditeur  (récepteur): 
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Ce  qu'il  comprend 


Ce  qu'il  accepte 


Ce  qu'il  retient 


r  \ 

ce  qu'il 
retransmet 


4.  Communiquer  quand? 

Au  lancement,  aux  échéances  annoncées,  lors  de  tout  évènement  (surtout  à  chaque 
jalon  par  le  maître  d'œuvre  au  maître  d'ouvrage!).  Demander  aux  mandants  et 
ressources  la  fréquence  avec  laquelle  ils  souhaitent  être  informés  et  sur  quoi  ils 
souhaitent  être  informés. 

5.  Communiquer  comment? 

Tous  les  moyens  sont  bons,  mais  outre  le  fait  que  le  style  doit  être  le  plus  simple  et 
standardisé  possible  l'implication  du  responsable  de  projet  et  de  l'équipe  est 
primordiale...  Ceci  dit  l'idée  de  faire  un  tableau  de  bord  avec  des  indicateurs  clés  (KPI) 
est  très  pertinente  car  en  un  coup  d'oeil  il  est  possible  d'avoir  une  petite  idée  de 
l'avancement  du  projet.  Adaptez  aussi  le  style  et  méthodes  de  communications  à 
l'environnement  du  projet! 

et  surtout  d'éviter  de  disperser  l'information  (typiquement  d'utiliser  les  e-mails)  en  utilisant 
des  plates-formes  Internet  pour  centraliser  toute  la  communication  du  projet  de  manière 
standardisée! 

Ci-dessous  un  schéma  qui  résume  très  bien  ce  qui  se  passe  lorsque  les  tâches  ne  sont  pas 
centralisées  et  que  les  gens  utilisent  les  vieilles  techniques  du  téléphone  ou  de  l'e-mail  (et  ce 
schéma  ne  rend  en  plus  pas  compte  du  problème  dit  du  "téléphone  arabe"...): 
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Client 


Figure  18  Ingérence  de  la  communication  (source:  ISBN  2708130226) 


Cependant  les  entreprises  souffrent  d'un  grave  problème  depuis  la  fin  des  trente  glorieuses. 
Effectivement  d'après  une  étude  du  PMI,  les  RH  considèrent  que  les  5  compétences  majeures 
d'un  bon  responsable  de  projet  sont  (en  %  de  la  population  totale  par  énumération): 


Compétences  de  communication 

84% 

Compétences  organisationnelles 

75% 

Esprit  d'équipe 

72% 

Leadership 

68% 

Compétences  techniques 

48% 

Or  le  problème  que  les  RH  des  entreprises  ont  a  priori  oublié  c'est  que  si  on  demandait  cela 
aux  scientifiques,  nous  en  serions  encore  à  la  machine  à  vapeur,  à  laver  le  linge  sale  dans  les 
rivières  et  à  descendre  de  la  neige  des  hauts  massifs  pour  préserver  nos  aliments  et  la  liste 
serait  encore  longue.  Ce  qu'ils  oublient  donc. . .  c'est  que  c'est  l'innovation  scientifique  et  la 
méthode  associée  qui  fait  avancer  le  monde  et  sa  condition  et  non  les  managers  et  les 
commerciaux  et  que  la  rigueur  scientifique  a  prouvé  sa  supériorité  dans  tous  les  domaines 
d'activité  de  services  ou  industriels  (c'est  connu  dans  le  monde  des  sciences  pures  que  cet  état 
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de  fait  énerve  les  personnes  travaillent  dans  les  sciences  molles  comme  le  sont  les  ressources 
humaines...  raisons  pour  lesquelles  elles  évitent  de  mettre  des  scientifiques  aux  postes  clés23). 

Nous  devrions  alors  avoir  plutôt  la  liste  des  compétences  souhaitées  suivante  (dans  l'ordre  du 
plus  au  moins  demandé): 


Éthique  et  responsabilité 

?% 

Esprit  analytique  et  de  synthèse 

?% 

Compétences  techniques 

?% 

Esprit  d'équipe 

?% 

Compétences  organisationnelles 

?% 

8.5.1  Les  quatre  styles  de  communication 

L'analyse  des  4  styles  de  communication  serait  fondée  sur  les  travaux  du  psychologue  suisse 
Cari  Gustav  Jung  (1875-1961).  Il  est  volontairement  simplifié  afin  de  le  rendre  utilisable  par 
chacun  dans  sa  vie  quotidienne.  Je  dois  admettre  que  ce  modèle  de  catégorisation  marche  très 
bien! 


“Your  smile  is  your  logo,  your 
personality  is  your  business 
card,  how  you  leave  others 
feeling  after  an  expérience 
with  you  becomes  your 
trademark." 


Des  travaux  cités  ci-dessus,  il  ressort  que  quatre  styles  de  communication  prédominent  dans 
les  relations  entre  les  personnes,  notamment  dans  le  cadre  professionnel.  Ces  quatre  styles 
sont: 


•  Le  rationnel 

•  L'affectif 

•  L'actif 

•  Le  conceptuel 


Et  on  les  retrouve  à  chaque  fois  dans  les  6  modes  de  communication  auxquels  fait  référence  le 
PMBOK: 


23  Par  ailleurs  un  certain  nombre  de  scientifiques  s’accordent  à  dire  que  les  premières  fonctions  qu'il  faudrait 
éradiquer  dans  les  entreprises  sont  les  RH  car  ils  ont  des  méthodes  de  travail  qui  sont  moyenâgeuses.  Il  y  a  même 
un  livre  fort  connu  dans  le  cercle  des  initiés  qui  en  donne  indirectement  une  forme  de  preuve... 
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1.  Interne  (propre  au  projet)  et  externe  (clients,  publique,  projets  connexes) 

2.  Formel  (rapports,  mémos,  briefings)  et  informels  (courriels,  discussions  diverses) 

3.  Vertical  (entre  les  différents  niveaux  hiérarchiques  des  acteurs  du  projet)  et  horizontal 

4.  Officiel  (newsletters,  rapports  annuels)  et  non  officiel  (communication  non  traçable) 

5.  Écrit  et  parlé 

6.  Verbal  et  non  verbal  (inflexion  de  voix  et  langage  du  corps) 

Il  est  clair  que  chaque  type  de  communication  marque  le  mode  de  travail,  de  management, 
etc. 

Nous  allons  voir  le  portrait  typique  de  chaque  modèle,  à  quoi  les  reconnaître  dans  la  vie 
professionnelle,  et  comment  communiquer  avec  eux  ou  avec  elles. 

Mais  ce  n'est  pas  tout  à  fait  aussi  simple  qu’il  y  paraît  ;  sans  entrer  dans  les  détails,  il  faut 
savoir  qu'une  personne  sous  stress  (manque  de  temps,  challenge  important,  émotion  intense, 
etc.)  va  certainement  changer  de  style  de  communication,  parfois  brutalement.  Nous  en 
parlerons  à  la  fin  de  ce  document. 

Ces  modes  de  communications  ne  rendent  pas  les  personnes  plus  ou  moins  sympathiques, 
cultivées,  généreuses  ou  honnêtes  ;  il  s'agit  juste  de  la  façon  dont  elles  communiquent. 

De  même,  si  d'un  pays  à  l'autre,  d'une  culture  à  l'autre,  les  attitudes  fondamentales  diffèrent,  il 
n'en  reste  pas  moins  qu'un  rationnel  méditerranéen,  sera  plus  expansif  que  son  homologue  de 
l'Europe  du  Nord.  Le  fait  qu'un  Américain  vous  appelle  par  votre  prénom  au  bout  de  2 
minutes  n'en  fait  pas  automatiquement  un  affectif,  parce  que  c'est  la  culture  générale. 

8. 5. 1.1  Le  rationnel 

Le  rationnel  est  typiquement  une  personne  qui  aime  se  référer  à  des  données  quantifiées,  à 
une  logique.  Ces  points  vont  conditionner  son  comportement  à  la  fois  dans  son  travail 
personnel,  son  organisation  et  bien  sûr  sa  communication  ;  qu'il  écoute  ou  qu'il  s'exprime,  ce 
sera  la  structure  de  son  discours  et  de  sa  mémorisation. 

C'est  à  ce  comportement  qu'on  peut  le  reconnaître.  Son  bureau  est  assez  rangé,  les  objets  sont 
alignés,  et  les  outils  rationnels  (ordinateur,  machine  à  calculer,  agenda,  etc.)  sont  en  évidence 
et  accessibles.  La  décoration  est  sobre,  régulière  et . . .  efficace. 

Lorsque  vous  parlez  avec  lui,  il  va  attendre  des  faits  quantifiés  (le  mot  «  beaucoup  »  n'a  pas 
grand  sens  pour  lui),  des  phrases  courtes  «  to  the  point  »,  pas  d'exubérance,  bref  sa  vision  de 
l'efficacité.  La  communication  écrite  est  du  même  style.  Il  s'attachera  plus  à  analyser  le  passé, 
qu'à  se  projeter  dans  l'avenir  ;  s'il  le  fait  ce  sera  conservateur  et  relativement  peu  créatif. 

En  réunion,  il  s'attend  à  ce  que  chacun  respecte  l'ordre  du  jour,  qu'il  y  ait  un  compte-rendu  des 
décisions,  et  que  l'horaire  soit  respecté. 

Dans  la  vie  professionnelle,  les  rationnels  occupent  souvent  des  fonctions  comptables, 
administratives,  financières,  parfois  dans  la  production. 

Il  n'aime  pas  être  surpris,  ce  qui  provoquera  un  stress  important,  et  le  fera  changer  de  mode  de 
communication.  Si  vous  connaissez  cet  autre  mode,  vous  pouvez  le  prévoir,  sinon  ce  sera  la 
surprise  et  donc  un  risque.  Il  est  plus  efficace  de  le  laisser  savoir  à  l'avance  ce  dont  vous  aller 
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parler,  il  pourra  se  préparer,  et  votre  relation  sera  plus  facile  et  efficace,  à  condition  de 
respecter  le  code  verbal. 

8. 5. 1.2  L'affectif 

Comme  le  nom  l'indique,  l'affectif  privilégie  l'affectivité  dans  ses  rapports  avec  les  autres. 
C'est-à-dire  qu'il  va  évaluer  votre  relation  en  fonction  de  l'affection  qu'il  va  sentir  se 
développer  et  des  émotions  qu'il  ressent  quant  à  vous,  votre  projet,  etc. 

L'affectif  est  généralement  assez  ouvert  pour  s'ouvrir  aux  autres  styles  de  communication,  ce 
qui  fait  qu'il  excelle  dans  la  vente  où  le  contact  est  essentiel.  Il  porte  aux  autres  un  intérêt 
véritable  et  s'efforce  de  le  lui  faire  comprendre  par  exemple  en  lui  posant  des  questions 
personnelles,  en  s'intéressant  à  sa  famille.  Il  a  besoin  de  visualiser  le  cadre  de  la  relation,  ou 
simplement  de  la  «  réchauffer  »  pour  bien  nouer  le  dialogue.  De  même,  il  vous  parlera 
spontanément  de  lui,  ou  prendra  des  exemples  personnels. 

Selon  les  cultures,  l'affectif  aura  plus  ou  moins  tendance  à  «  toucher  »  l'épaule,  le  bras  de  son 
interlocuteur,  pour  avoir  un  contact  plus  étroit,  mais  il  le  fera  plus  que  les  autres  modèles  de 
communication. 

Son  bureau  parle  pour  lui  ;  il  y  a  bien  sûr  sa  famille,  parfois  ses  amis,  des  images  du  passé, 
des  diplômes,  bref  ce  qui  a  marqué  sa  vie  et  ce  qui  constitue  ses  points  de  repère. 

En  réunion,  c'est  malheureusement  celui  qui  sera  souvent  le  plus  rapide  à  faire  une  digression, 
mais  aussi  le  plus  efficace  à  trouver  les  terrains  d'entente  pour  résorber  les  conflits. 

Ce  sont  souvent  des  vendeurs,  mais  ensuite,  ils  évoluent  dans  la  hiérarchie,  et  puisque  la  vente 
mène  à  tout,  nous  les  retrouvons  dans  pratiquement  toutes  les  fonctions  de  management,  sauf 
peut-être  en  finance,  et  en  industrie. 

L'affectif  est  en  principe  toujours  disponible  (son  emploi  du  temps  est  donc  surchargé),  mais 
il  ne  faut  pas  le  brusquer  car  il  n'aurait  pas  le  temps  d'établir  sa  relation. . .  Il  lui  faut  donc  du 
temps  pour  commencer,  et  pour  conclure.  Entre  deux,  les  choses  peuvent  aller  vite  car  il  vous 
fera  confiance,  tant  que  vous  resterez  sur  le  mode  affectif.  Si  vous  ne  respectez  pas  son  mode 
de  communication,  il  se  méfiera,  deviendra  stressé,  et  changera  de  mode  de  communication! 

8. 5. 1.3  L'actif 

C'est  clair,  il  bouge  et  fait  beaucoup  bouger.  Les  questions  se  succèdent  sans  qu'il  ait  vraiment 
le  temps  d'en  écouter  les  réponses  ;  en  fait  ce  sont  plutôt  des  directives  que  des  questions, 
parce  que,  si  vous  êtes  devant  lui,  c'est  que  vous  faites  déjà  partie  de  ses  projets  ou  que  cela  ne 
va  pas  tarder. 

Sa  perception  de  la  vie  se  résume  aux  actions  qu'il  conduit,  ou  auxquelles  il  participe.  Son 
emploi  du  temps  est  chargé,  souvent  fractionné,  et  laisse  peu  de  temps  à  la  réflexion.  C'est 
également  l'image  qu'il  donne.  Ce  qui  frappe,  c'est  l'énergie  dont  il  fait  preuve. 

Ne  lui  demandez  pas  de  vous  laisser  le  temps  de  la  réflexion  ;  il  ne  le  comprendrait  pas,  et 
n'en  a  pas  le  temps  ;  au  contraire  entrez  dans  le  jeu  et  dans  l'action.  C'est  à  ce  prix  qu'il 
communiquera  avec  vous  et  gardera  un  bon  souvenir  de  votre  «  conversation  »... 
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La  principale  limite  de  l'actif  est  qu'il  doit  avoir  la  compétence  de  base  pour  être  efficace, 
sinon  sa  quête  d'action  se  réalise  en  pure  perte,  car  il  ne  connaît  pas  le  territoire  sur  lequel  il 
dépense  son  énergie. 

Son  bureau  vous  éclairera,  si  tant  est  qu'il  en  ait  un!  En  effet,  le  bureau  typique  de  l'actif  est 
encombré,  sans  ordre  apparent,  mais  il  s'y  retrouve,  ou  du  moins  il  en  donne  l'impression. 
Certains  actifs  ont  franchi  la  limite  et  n'ont  plus  de  bureau  personnel,  ils  se  posent  à  proximité 
de  leur  secrétaire,  ainsi  qu'à  côté  de  leurs  collaborateurs.  Pour  eux  ce  qui  compte  c'est  de 
piloter  et  de  construire.  C'est  ainsi  qu'ils  mesurent  leurs  résultats,  et  éventuellement  les  vôtres. 
Ils  travaillent  dans  les  couloirs,  dans  la  rue,  au  restaurant,  partout  où  c'est  le  moment. . . 

En  réunion,  l'actif  ne  respectera  pas  l'ordre  du  jour  (sauf  si  c'est  le  sien. . .),  mais  sera  le 
premier  à  s'impatienter  et  à  se  plaindre  de  l'absence  de  résultat.  Pour  cadrer  un  sujet,  il  suffit 
de  lui  donner  la  parole,  mais  de  la  lui  retirer  à  temps  avant  que  tout  le  monde  ait  fui. 

Les  actifs  sont  souvent  dans  la  production,  ou  à  la  direction  générale,  jouant  le  rôle  d'un 
homme-orchestre.  L'entreprise  est  fortement  axée  sur  les  résultats. 

Il  n'aime  pas  perdre  son  temps,  et  son  aspect  opportuniste  cache  une  certaine  fidélité.  Il  n'agit 
pas  sur  un  coup  de  tête,  et  sa  confiance  se  mérite.  En  fait  il  est  constamment  sur  le  qui-vive  et, 
dans  sa  tête,  les  dossiers  sont  prêts.  Pour  travailler  avec  lui  il  faut  préparer  ses  cartouches  et 
savoir  les  utiliser  à  bonne  cadence.  Il  vaut  mieux  ajourner  une  réunion  que  de  laisser  des 
temps  morts  s'installer. 

Son  esprit  s'intéresse  d'abord  aux  conséquences  des  actes  et  des  décisions  à  prendre  pour  les 
analyser  et  décider  à  court  terme.  Il  est  également  l'intuitif. 

Pour  mener  à  bien  son  approche  des  choses  et  des  gens,  il  a  besoin  de  temps,  et  son  rythme  de 
travail  est  relativement  plus  lent  que  celui  de  ses  collègues.  En  fait  quand  il  approfondit  un 
sujet,  il  va  de  plus  en  plus  vite,  car  il  capitalise  sur  ses  analyses.  C'est  un  des  principaux 
indicateurs  pour  l'identifier. 

Quand  vous  échangez  avec  lui,  vous  remarquerez  qu'il  va  spontanément  prendre  du  recul,  et 
éventuellement  vous  proposer  une  approche  plus  globale,  et  plus  long  terme.  Cette  démarche 
peut  sembler  pesante,  mais  elle  est  très  puissante. 

Son  bureau,  s'il  n'est  pas  nécessairement  zen,  est  serein,  calme.  L'ordre  n'y  règne  pas  en 
maître,  mais  suffisamment  pour  pouvoir  travailler.  Il  aime  vous  accueillir,  et  partager  avec 
vous  ses  visions.  La  décoration  est  assez  facilement  ...conceptuelle,  ou  composée  d'objets  de 
qualité,  si  possibles  authentiques.  C'est  peut-être  un  fumeur  de  pipe. 

En  réunion,  il  ne  s'intéressera  qu'à  un  ou  deux  points  de  l'ordre  du  jour,  et  encore!  En  fait  il 
enrichira  la  réunion  d'éléments  clés  qui  permettront  de  mieux  situer  une  problématique,  ou  de 
réviser  une  allocation  de  ressources,  etc. 

8. 5. 1.4  Le  conceptuel 

Les  conceptuels  se  trouvent  dans  la  recherche,  le  planning,  la  stratégie,  et  donc  également  à  la 
tête  des  organisations,  qui  invariablement  intègrent  le  long  terme  dans  leurs  valeurs. 
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Il  n'aime  pas  être  confronté  à  une  accumulation  de  détails  et  de  décisions  à  court  terme.  C'est 
le  meilleur  moyen  de  le  stresser  et  de  le  faire  changer  de  mode  de  communication,  mais 
souvent  en  pure  perte,  puisque,  dès  le  calme  revenu,  il  va  prendre  le  temps  de  revoir  ses 
décisions  par  rapport  au  long  terme.  Éviter  par  exemple  de  l'associer  étroitement  à  une  cellule 
de  crise  où  il  n'aurait  pas  sa  place,  mais  lui  soumettre  les  décisions  pour  prendre  du  recul. 


8.5.2  Des  mesures  pour  réduire  le  nombre  d'e-mails 

Alors  que  la  culture  digitale  s'est  très  largement  répandue  dans  l'entreprise,  le  mauvais  usage 
du  mail  s'accentue  paradoxalement  et  impacte  durablement  la  productivité.  Comment 
sensibiliser  chacun  à  la  nécessité  de  réduire  le  nombre  de  mails  envoyés? 

La  perte  de  productivité  liée  aux  mails  inutiles  est  colossale.  Et  malheureusement  il  n'existe 
pas  de  filtres  antispam  internes  pour  éliminer  automatiquement  les  mails  inutiles. 

Considérons  une  entreprise  de  5 '000  employés  et  admettons  que  chacun  gère  une  centaine  de 
mails  par  jour  et  que  la  plupart  de  ces  mails  sont  internes  à  l'entreprise.  Cela  fait  environ  100 
millions  de  mails  par  an.  Considérons  enfin  qu'il  faille  en  moyenne  une  minute  pour  traiter  un 
mail.  Il  s'agit  là  d'un  simple  ordre  de  grandeur  bien  évidemment. 

Si  nous  pouvions  réduire  de  10%  le  nombre  de  mails  reçus  (et  donc  envoyés),  le  gain  de 
productivité  serait  colossal.  Dans  cet  exemple,  il  permettrait  de  gagner  l'équivalent  d'environ 
100  postes  à  temps  plein.  Simplement  en  diminuant  de  10  %  le  nombre  de  mails!  !  ! 

Personnellement  je  préconise  deux  solutions  qui  vont  de  la  méthode  douce  à  la  méthode  qui 
touche  au  porte-monnaie.  Il  va  sans  dire  que  les  deux  doivent  être  strictement  appuyées  par  la 
direction  de  l'entreprise  pour  avoir  un  effet  et  par  le  département  IT  pour  extraire  les 
statistiques  nécessaires!: 

•  Méthode  douce:  Imaginez  un  concours  ouvert  à  tous  les  employés,  quel  que  soit  leur 
statut  ou  leur  métier.  Les  participants  sont  aléatoirement  répartis  dans  des  groupes 
d'une  trentaine  de  personnes  pour  s'affranchir  des  disparités  liées  au  métier  de  chacun. 
Au  début  du  concours,  l'ensemble  des  e-mails  envoyés  par  chaque  groupe  pendant 
l'année  écoulée  est  calculé  et  rendu  public.  Tous  les  mois,  les  efforts  de  réduction  des 
mails  envoyés  par  ces  participants  sont  également  rendus  publics  afin  de  stimuler 
l'esprit  de  compétition. 

Au  bout  d'un  an,  si  l'objectif  de  10  %  de  réduction  des  mails  est  atteint  pour  l'ensemble 
des  participants,  le  groupe  qui  aura  fait  le  plus  bel  effort  se  verra  récompensé  (par 
exemple  à  hauteur  d'un  iPad  par  participant). 

Le  coût  total  de  l'opération  se  chiffrerait  alors  pour  l'entreprise  à  une  somme  bien 
dérisoire  par  rapport  au  temps  (ou  aux  postes  d'emploi...)  gagné  de  manière  durable 

•  Méthode  forte:  Cette  méthode  consiste  simplement  à  facturer  au  prix  du  timbre  de  la 
poste  classique  les  e-mails  échangés  entre  département  et  avec  les  partenaires 
extérieurs...  Cela  calme  tout  de  suite  les  esprits  de  certains  et  a  un  effet  là  aussi  durable 
puisque  de  nombreux  centre  de  coûts  traditionnels  seront  touchés... 
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Vincent  ISOZ 


Enfin,  la  pratique  semble  indiquer  que  de  fournir  un  seul  et  unique  point  de  contact  et  canal  de 
communication  aux  clients  est  grandement  apprécié  par  ses  derniers.  Cela  permet  par  ailleurs 
quand  bien  appliqué  de  garder  les  clients  satisfaits  grâce  à  une  prise  en  charge  efficace  et 
professionnelle  de  toutes  les  demandes  de  service. 

8.6  Cycle  de  vie  d’un  projet 

Les  projets  sont  des  réalisations  uniques  qui  impliquent  nécessairement  un  certain  degré 
d'incertitude  en  ce  qui  a  trait  aux  probabilités  de  succès.  Les  organisations  qui  exécutent  des 
projets  divisent  normalement  ceux-ci  en  plusieurs  phases  afin  d’en  permettre  une  meilleure 
gestion  et  un  contrôle  adéquat:  identification,  planification,  réalisation  et  terminaison. 

Collectivement,  ces  phases  sont  mieux  connues  (globalement  ou  individuellement)  sous  le 
nom  de  cycle  de  vie  de  projet,  chacune  étant  marquée  par  la  réalisation  d'un  ou  de  plusieurs 
biens  livrables. 

Remarque:  Par  définition,  un  bien  livrable  est  un  produit  tangible,  vérifiable. 

Les  figures  ci-dessous  illustrent  quelques  modèles  particuliers24  des  phases  du  cycle  de  vie 
d'un  projet  (la  première  étant  représentée  empiriquement  sous  la  forme  d'une  distribution 
bêta). 

Nous  avons  d'abord  le  fameux  modèle  en  4  phases  (étapes)  qui  est  probablement  le  plus 
élémentaire  avec:  Identification,  Planification,  Réalisation,  Terminaison: 


Effort  Objectifs  du 


24  Nous  avons  déjà  mentionné  qu'il  existe  des  modèles  de  cycle  pour  la  majorité  des  standards  de  la  gestion  de 
projets.  Celui  du  PMBOK  étant  relativement  complet  nous  conseillons  au  lecteur  d'y  jeter  un  coup  d'œil! 
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Identification 

Planification 


Terminaison 


Ou  selon  le  PM2: 


Les  phases  du  projet  font  partie  d'une  séquence  logique  ce  qui  permet  d'assurer  une  définition 
acceptable  du  produit  obtenu.  Pour  la  gestion  informatisée  de  projet  qui  nous  concerne,  nous 
vous  proposons  le  modèle  présenté  à  la  figure  ci-dessus  comprenant  5  phases  (étapes), 
nommément:  Identification,  Planification,  Mise  en  place  informatisée,  Pilotage 
informatisé,  Terminaison. 

Sinon  voici  un  autre  schéma  un  peu  plus  détaillé: 
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25  II  existe  de  nombreux  types  différents  de  "matrices  d'analyse  des  tâches"  (tableau  à  double  entrée): 
tâche/responsable,  tâche/priorité,  tâche/tâche  avec  corrélation,  etc. 
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ou  encore  un  peu  plus  détaillé  (ma  version  personnelle): 


r 


IDENTIFIER 


r 


PLANIFIER 


j 

1.  Besoins 

2.  Analyse  préliminaire 

3.  Évaluation  du  concept 

4.  Prospecter(Audit,SWOT) 

5.  Objectifs/Buts 

6.  Projets  précédents? 

7.  Choix/Options 

8.  Analyse  fonctionnelle/ 
structurelle 

9.  Benchmarking 

10.  Faisabilité/Defi 

11.  Ressources  (capacité?) 

12.  Intervenants 

13.  Disponibilités 

14.  Finances  (inflation) 

15.  Responsabilités 

16.  O. B. S 

17.  Risques  (AMDEC/SdF) 

18.  Facteurs  externes 

19.  Outils IT/Normes/AQ. 

20.  Garantie  produit 

21.  Lois/Copyrights/Brevets 

22.  Pénalités 


1.  Planif.  ATO/ATA 

2.  Jalonnement 

3.  Tâches  (QQ.OQCPC) 

4.  Ressources 

5.  W.B.S/O.B.S./ PB.S... 

6.  Optimisation 

7.  Frais/Coûts 
(budg.  prévisionnel) 

8.  Honoraires 

9.  Calendriers 

10.  Processus/Flux 

11.  Gantt/PERT 

12.  Dépendances 

13.  Contraintes 

14.  Deadlines 

15.  Calcul  risques 

16.  Chemin  critique 

17.  Marges 

18.  Validation 


23.  Rédaction  PDP,  Chartes 

24.  Validation 
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r - \ 

SIMULER 

■> - , 

1.  Simulation  tâches 

2.  Simulation  organisation 

3.  Simulation  processus 

4.  Simulation  dépendances 

5.  Simulation  implémentation 

6.  Corrections 

7.  Validation 


Modèle  de  contrôle 
à  rétroaction 


f - \ 

RÉALISER 

\ - à 

1.  Suivi 

2.  Reunions 

3.  Mises  à  jour 

4.  Corrections 

5.  Communication 

6.  Performances (KPI) 

7.  QC  (Quality  Control) 

8.  Optimisation 

9.  Chemin  critique 

10.  Marges 

11.  Motivation  de  I  équipé 

12.  Création  processus 

13.  Validation 


Modèle  de  contrôle 
à  rétroaction 


r 

A 

TERMINER 

1.  Formations 

2.  Tests  et  calculs  de  fiabilité 

3.  Certifications/Homologations 

4.  Comparaison  planification 

5.  Finalisation  doc. 

6.  Rapport  client 

7.  Rapport  interne 

8.  Mesures  pour  l'avenir 

9.  Sauvegarde  statistiques 

10.  Stockage  données 

11.  Validation 

12.  Clore  marketingde  projet 

13.  Clore  sûreté  des  données 

14.  Clore  assurance  qualité 

15.  Clore  gestion  des  risques 

16.  Apero 

17.  Gratifications 

18.  Suivi  des  modifications 
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Légende: 

-  SWOT:  Strengths,  Weaknesses,  Opportunities,  Threads 

-  AMDEC:  Analyse  des  Modes  de  Défaillance  et  de  leur  Criticité 

-  SdF :  Sûreté  de  fonctionnement 

-  AQ:  Assurance  Qualité 

-  QQOQCP(P):  Qui  Quoi  Où  Quand  Combien  Pourquoi,  (Pour  Quoi?) 

-  ATO:  Au  plus  tôt 

-  ATA:  Au  plus  tard 

-  W.B.S.:  Work  Breakdown  Structure  (structure  des  tâches  du  projet  sous  forme  d'organigramme) 

-  P.B.S.:  Product  Breakdown  Structure  (structure  du  produit  sous  forme  d'organigramme) 

-  O.B.S.:  Organisational  Breakdown  Structure  (structure  qui  permet  de  mettre  en  relation  PB  S  avec  WBS 
pour  identifier  les  responsabilités) 

-  L.B.S..:  Localisation  Breakdown  Structure 

-  PERT:  Program  Evaluation  Review  Technic 

-  KPI:  Key  Performance  Indicator  (IPC:  Indicateur  de  Performance  Clé) 

Pendant  l’explication  du  modèle  ci-dessus,  le  formateur  vous  demandera  d’ouvrir  MS  Office 
Project,  MS  Office  Visio  et  MS  Office  Excel  pour  certains  exemples  pratiques  (qui  ont  été 
simplifiés  pour  commencer!). 

L’idéal  dans  la  réalité  est  cependant  de  faire  une  check-list  adaptée  à  votre  domaine  d’activité 
concernant  le  cycle  de  vie  du  Projet.  Un  bon  exemple  dont  on  peut  s’inspirer  est  celui  proposé 
par  la  méthodologie  Hermès  dans  son  PDF  gratuit  intitulé  Guide  de  poche ,  qui  contient  une 
check-list  d’une  quarantaine  de  pages  très  bien  faite 

Pour  ceux  qui  ne  trouveraient  pas  le  PDF  sur  Internet,  voici  un  copier/coller  brut  du  modèle 
de  phases  avec  les  critères  d’évaluations  de  chacune. 


Annonce 
de  projet 


Mandat 
de  projet 


Feu  vert 

conception  /  évaluation 


Fou  vert 
Introduction 


Feu  vert 
finalisation 


Initialisation 


Analyse 


i 


Conclusion 
du  projet 


Construction  du  système 


i 


U 

Accord  sur  Choix  de 

les  objectifs  la  sol  ution 

Feu  vert  réalisation 

1 

Développement  de  systèmes  DS 

Conception  f  Réalisation 

W  AI  C/ 

Concept  Spécification  Achèvement 

du  système  du  système 

Feu  vert  implémentation 

Adaptation  de  systèmes  AS 

______________ 

Evaluation  f  Implémentation 

-o- 

Dossier 

d'appel 

d'offres 


O 

Choix 
de  l'offre 


Spécification 
du  système 


Adaptation 
du  système 


Introduction 

)  Q  O 


Finalisation 


i 


Migration  ]  Réception 
du  système  du  système 

Mise  en  service 
(seulement  AS3 


Point  de  décision  de  phase 
O  Point  de  décision 
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Point  de  décision  de  phase:  mandat  de  projet 


Résultat  Critères  d'évaluation 


Proposition  *  La  proposition  est-elle  conforme  à  la  stratégie  de  l'entreprise? 

de  projet  *  Le  projet  est-il  «nécessaire»  ? 

*  Le  portefeuille  de  projets  est-il  pris  en  compte,  la  délimitation  avec  d'autres  projets 
est-elle  clarifiée? 


*  Toutes  les  parties  prenantes  sont-elles  informées  et  ont-elles  été  écoutées  ? 

*  Les  dispositions  légales  sont-elles  respectées  ? 

*  Les  objectifs  sont-ils  clairs  et  réalistes  ? 

*  A-t-on  analysé  dans  quelle  mesure  des  solutions  existantes  pouvaient  être  utilisées  ? 

*  Les  risques  sont-ils  identifiés  et  les  mesures  à  prendre  sont-elles  définies  (ou:  un  processus 
de  gestion  des  risques  est-il  mis  en  place)? 

*  La  qualité  souhaitée  est-elle  documentée  et  un  processus  de  gestion  de  la  qualité  est-il 
mis  en  place? 

*  Les  points  de  décision  et  les  résultats  sont-ils  tous  définis? 


Proposition  *  Les  ressources  sont-elles  disponibles  :  finances,  personnel  (collaborateurs  disposant  du 
de  projet  savoir-faire  opérationnel,  informaticiens,  etc.),  matériel  ? 

*  Le  calendrier  est-il  réaliste? 


»  Le  projet  a-t-il  un  sens  au  niveau  QJR  (coût/ utilité/rentabilité)? 
*  Les  conditions  cadres  sont-elles  décrites  de  manière  réaliste  ? 


*  Le  comité  de  projet  (CoP)  est-il  composé  des  personnes  adéquates  ? 

*  Un  processus  de  gestion  des  modifications  est-il  mis  en  place  pour  maîtriser  le  périmètre  du 
projet?  La  responsabilité  du  volume  du  projet  incombe  au  donneur  d'ordre  et  au 

comité  de  projet. 


Point  de  décision:  accord  sur  Iles  objectifs 


Résultat 

Critères  d'évaluation 

Analyse  de 
la  situation 

*  Le  champ  d'analyse  englobe-t-il  toutes  les  solutions  envisageables?  Ne  doit-il  pas  être  élargi  ? 

*  L'analyse  a-t-elle  été  effectuée  ? 

*  La  sûreté  de  l'information  et  la  protection  des  données  ont-elles  été  analysées  et  évaluées  en 
fonction  de  la  situation? 

Objectifs 
du  système 

*  Les  objectifs  du  système  correspondent- ils  aux  problèmes  à  résoudre  (besoins)  d'après  l'analyse 
de  la  situation? 

*  Les  objectifs  du  système  n'entrent-ils  pas  en  conflit  avec  les  conditions  cadres  du  projet? 

*  Les  objectifs  du  système  sont-ils  en  accord  avec  ceux  de  l'entreprise  ? 

*  Les  objectifs  du  système  comprennent-ils  aussi  des  objectifs  adéquats  pour  la  sûreté  de 
l'information  et  la  protection  des  données? 
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Point  de  décision:  choix  de  la  solution 


Résultat 

Critères  d'évaluation 

Exigences 
envers 
le  système 

*  A-t-on  pris  acte  des  exigences  posées  envers  le  système  par  les  acteurs  les  plus  importants 
(donneur  d'ordre,  utilisateur,  exploitation)? 

*  Est-on  sur  de  n'avoir  oublié  aucun  acteur  important? 

*  Les  exigences  envers  le  système  sont-elles  suffisamment  détaillées  pour  la  phase  actuelle  ? 

*  Les  exigences  envers  Ile  système  sont-elles  cohérentes  et  non  contradictoires? 

*  A-t-on  défini  tant  les  exigences  fonctionnelles  que  les  exigences  non  fonctionnelles  envers 
le  système? 

Propositions 
de  solution 

•  Les  objectifs  du  système  laissent-ils  une  marge  de  manœuvre  suffisante  à  la  recherche  de 
la  solution? 

•  Les  objectifs  fixés  pour  le  système  sont-ils  réalistes  ? 

*  Toutes  les  solutions  envisageables  ont-elles  été  analysées? 

•  A-t-on  analysé  si  des  solutions  en  préparation  ou  déjà  existantes  peuvent  être  utilisées? 

*  Les  propositions  de  solution  remplissent-elles  les  objectifs  et  les  exigences  fixés  envers 
le  système?  En  particulier,  tous  les  objectifs  et  exigences  en  matière  de  sécurité  de 
Linformatique  et  de  protection  des  données  sont-ils  satisfaits? 


Propositions 
de  solution 


*  La  justification  de  la  solution  proposée  est-elle  adéquate  et  suffisante  ? 

*  L'utilisation  de  produits  finis  a-t-elle  été  analysée  de  manière  suffisante? 

*  La  solution  proposée  est-elle  intégrée  dans  l' environ  ne  ment? 

*  La  solution  proposée  bénéficie-t-elle  du  soutien  du  bénéficiaire/ utilisateur  de  la  solution? 

*  la  solution  proposée  tient-elle  compte  d'une  possible  évolution  de  l'environnement?  N'est- 
elle  pas  adaptée  uniquement  à  la  situation  actuelle? 

*  Les  effets  possibles  de  la  solution  ont- ils  été  analysés  et  évalués  ? 

*  la  solution  proposée  est-elle  techniquement  réalisable? 

*  La  rentabilité  de  la  solution  est-elle  réaliste  et  plausible? 

*  Le  choix  entre  une  solution  de  type  développement  ou  adaptation  de  systèmes  a-t-il  été 
analysé? 


Point  de  décision  de  phase:  feu  vert  à  la  phase  de  conception  ou  évaluation 


Résultat 

Critères  d'évaluation 

Rapport 

d'analyse 

préliminaire 

•  Le  rapport  a-t-ïl  été  soumis,  pour  prise  de  position,  à  toutes  les  personnes  concernées? 

•  Le  rapport  résume-t-il  les  résultats  et  la  base  de  décision  de  manière  compréhensible  et 
correcte? 

•  Les  mesures  planifiées  pour  l'assurance  de  la  qualité  ont-elles  été  exécutées  avec  succès  ? 
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Point  de  décision:  concept 


Résultat 

Critères  d'évaluation 

Produits  finis 
et  moyens 
matériels 

*  L'utilisation  de  produits  finis  a-t-elle  été  suffisamment  analysée  ? 

*  La  décision  de  développer  une  solution  au  lieu  d'utiliser  un  produit  fini  est-elle  justifiée 
et  adéquate? 

*  Les  procédures  introduites  avec  le  produit  fini  ont-elles  été  intégrées  dans  la  solution  ? 

*  Les  produits  finis  remplissent-ils  les  objectifs  et  les  exigences  de  la  sécurité  de 
l'informatique  et  de  la  protection  des  données? 

Etudes 
détaillées  et 
prototypes 

*  Les  sous-sysjtémes  critiques  ont-ils  été  déterminés  ? 

*  Les  objectifs,  l'étendue  et  la  profondeur  des  analyses  ont-ils  été  définis  au  moyen  d'un 
prototype  ou  d'une  étude  détaillée? 

*  Les  résultats  des  études  détaillées  et  des  prototypes  ont-ils  été  intégrés  dans  le  concept  ? 

*  D'autres  variantes  ont-elles  été  analysées  pour  le  concept  ? 

Résultats 
de  la 

conception 

*  Les  exigences  envers  le  système  sont-elles  claires,  sans  contradictions  et  réalistes  ?  Leur 
respect  est-il  vérifiable? 

*  Les  exigences  envers  le  système  ne  dépendent-elles  pas  de  décisions  cachées  au  niveau 
du  design  (réalisation)? 

Résultats  • 

de  la 

conception  • 

* 

• 

• 

L'architecture  du  système  couvre-t-elle  de  manière  plausible  toutes  les  exigences?  La  sûreté 
de  rinformation  et  la  protection  des  données  sont-elles  notamment  assurées? 

Le  concept  est-il  suffisamment  détaillé? 

Le  concept  proposé  est-il  convaincant  et  réalisable  sous  tous  ses  aspects  (matériels, 
financiers,  informatiques,  logiciels,  organisationnels,  sécurité  de  l'informatique,  protection 
des  données)? 

Le  concept  bénéficie-t-il  du  soutien  du  département  spécialisé  (bénéficiaire  et  utilisateur 
du  système)  ? 

Les  risques  et  l|es  problèmes  de  la  réalisation  et  de  l'introduction  qui  vont  suivre  ont-ils  été 
suffisamment  clarifiés  ? 

Point  de  décision  de  phase:  feu  vert  à  la  phase  de  réalisation 


Résultat 

Critères  d'évaluation 

Rapport  de 
conception 

•  Le  rapport  a-t-il  été  soumis,  pour  prise  de  position,  à  toutes  les  personnes  concernées  ? 

•  Le  rapport  résume-t-il  les  résultats  et  la  base  de  décision  de  manière  compréhensible 
et  correcte  ? 

•  Les  mesures  planifiées  pour  l'assurance  de  la  qualité  ont-elle  été  exécutées  avec  succès? 
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Point  de  décision:  spécification  du  système 


Résultat 

Critères  d'évaluation 

Spécification  du 

*  Le  design  du  système  reste-t-il  dans  le  cadre  prescrit  par  le  concept? 

système  {exigences 

*  Les  exigences  envers  le  système  (par  rapport  à  son  design)  sont-elles  claires,  sans 

envers  Ile  système, 

contradictions  et  réalistes?  Leur  respect  est-il  vérifiable? 

design  du  système, 

*  Le  design  du  système  couvre-t-il  de  manière  plausible  toutes  les  exigences  envers 

design  de  la 

ce  dernier? 

migration) 

*  Le  design  de  la  migration  tient-il  compte  de  tous  les  problèmes  et  risques  importants? 

*  Les  aspects  organisationnels  ont-ils  été  suffisamment  pris  en  compte  ? 

*  La  solution  de  secours  |en  cas  de  panne  du  système  satisfait-elle  aux  besoins? 

*  La  spécification  du  système  constitue-t-elle  une  base  suffisante  pour  la  réalisation 

de  celui-ci  ? 

*  Un  environnement  de  test  a-t-il  été  mis  en  place  ?  Des  spécifications  de  test 

adéquates  ont-elles  été  formulées  pour  tous  les  éléments  du  système  définis  dans 

le  plan  d'examen? 

Prototypes 

*  Le  prototype  est-il  intégré  comme  résultat  dans  la  spécification  du  système  ? 

*  Toutes  les  variantes  envisageables  de  la  spécification  du  système  ont-elles  été 

analysées? 

Point  de  décision:  achèvement  du  système 


Résultat 

Critères  d'évaluation 

Manuel 

d'organisation,  pro¬ 
cédure  de  migration, 
manuel  d'utilisation, 
moyens  matériels, 
manuel  de  support 

•  Le  système  réalisé  couvre-t-il  les  objectifs,  les  exigences  et  l'architecture  spécifiés  ? 

•  Les  directives  et  les  normes  de  développement  à  appliquer  ont-elles  été  respectées  ? 

•  Les  comptes-rendus  de  test  confirment-ils  la  maturité  du  système  ? 

•  Des  mesures  efficaces  ont-elles  été  prises  pour  éliminer  les  défauts  constatés  ? 

•  Les  unités  d'organisation  concernées  ont-elles  été  informées  de  manière  adéquate 
sur  le  projet? 

•  Le  concept  de  formation  se  base-t-il  sur  les  qualifications  dont  disposent  les 
personnes  concernée^? 

•  Les  risques  de  migration  vers  le  système  cible  ont-ils  été  identifiés  et  réduits  au  mini¬ 
mum  possible  par  des  mesures  appropriées? 

Point  de  décision  de  phase:  feu  vert  à  la  phase  d'introduction 


Résultat 

Critères  d'évaluation 

Rapport  de 

*  Le  rapport  a-t-il  été  soumis,  pour  prise  de  position,  à  toutes  les  personnes  concernées? 

réalisation 

•  Le  rapport  résume-t-il  les  résultats  et  la  base  de  décision  de  manière  compréhensible 

et  correcte  ? 

*  Les  mesures  planifiées  pour  l'assurance  de  la  qualité  ont-ellle  été  exécutées  avec  succès? 
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Point  de  décision:  dossier  d'appel  d'offres 


Résultat  Critères  d'évaluation 


Cahier  des  charges 

*  L'étude  des  produits  est-elle  exhaustive  ? 

*  Les  descriptions  des  exigences  envers  les  produits  sont-elles  suffisamment  détaillées? 

*  Les  contrôles  concernant  les  aspects  légaux  des  délais  et  des  critères  d'adjudication 
ont-ils  été  effectués  ? 

*  Les  exigences  telles  que  détaillées  permettent-elles  la  conclusion  d'un  contrat 
immédiatement  après  la  procédure  de  soumission? 

Catalogue  des 
critères 

*  Les  critè  res  f  or  m  u  1  és  pe  r  m  e  tten  t-ï  1  s  d  révi  te  r  tou  te  d  i  scr  i  m  i  n  a  t  io  n  ? 

*  Le  catalogue  des  critères  distingue-t-il  les  critères  «  obligatoires  »,  «  souhaités  »  et 
«  possibles»  ? 

Texte  de  l'appel 
d'offre 

*  La  base  d'évaluation  des  critères  est-elle  claire  et  compréhensible  ? 

*  Le  catalogue  des  critères  tel  que  présenté  est-il  suffisamment  clair  pour  être  envoyé 
avec  le  cahier  des  charges  ? 

*  Le  texte  de  l'appel  d'offre  est-il  complet  et  sans  équivoque? 

*  Le  texte  de  l'appel  d'offre  correspond-il  aux  exigences  légales? 

Questionnaire 
(demande  de 
participation) 

*  Les  questions  sont-elles  claires  et  sans  équivoque  ? 

*  Le  questionnaire  correspond-il  aux  exigences  légales  ? 
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Point  de  décision:  choix  de  l'offre 


Résultat 

Critères  d'évaluation 

Rapport 

d'évaluation 

*  Les  résultats  de  l'évaluation  sont-ils  clairs? 

*  Les  exigences  légales  ont-elles  été  respectées  lors  du  choix? 

*  Tous  les  critères  d'exclusion  ont-ils  été  pris  en  compte  lors  du  choix? 

*  La  décision  prise  prend -elle  en  compte  tous  les  critères  d'adjudication  tells  que  formulés 
dans  le  dossier  d'appel  d'offre? 

*  Le  choix  présenté  tient-il  compte  des  conditions-cadres  sur  le  plan  financier  ? 

Choix  *  Le  «  choix  de  l'offre  »  correspond-ïl  aux  exigences  légales? 

de  1  offre  *  La  décision  est-elle  clairement  compréhensible  pour  tous  les  soumissionnaires  ? 

*  Les  soumissionnaires  sont-ils  informés  des  voies  de  recours  ? 

Point  de  décision  de  phase:  feu  vert  à  la  phase  d 'implémentation 

Résultat 

Critères  d'évaluation 

Contrat  ou 
convention  de 
projet 

*  Le  fournisseur  de  prestations  et  le  bénéficiaire  de  prestations  sont-ils  clairement  définis? 

*  La  durée  de  validité  du  contrat  est-elle  définie  et  cohérente  avec  le  plan  de  projet? 

*  L'étendue  des  prestations  est-elle  clairement  définie  en  termes  de  résultats  à  fournir, 
des  délais  à  respecter,  des  objectifs  du  système  et  des  exigences  envers  Ile  système,  des 
caractéristiques  de  qualité.,  du  pilotage  de  projet,  de  la  réception  des  résultats  à  fournir 
et  des  prestations  non  incluses? 

*  Les  devoirs  de  collaboration  du  bénéficiaire  de  prestations  sont-ils  clairement  définis  ? 

*  Les  parties  prenantes  internes  ont-elles  été  informées  des  devoirs  de  collaboration  du 
bénéficiaire  de  prestations? 

*  Les  exigences  en  termes  de  protection  et  sécurité  des  données  sont-elles  clairement  définies? 

*  Les  procédures  de  gestion  des  modifications,  d'information  (rapports  de  projet)  et  de 
traitement  des  problèmes  (transfert  en  escalade)  sont-elles  clairement  formalisées? 

*  Les  coûts  de  projet  sont-ils  clairement  définis? 

*  Les  conditions  du  passage  à  l'exploitation  sont-elles  clairement  définies? 

*  L'assistance  pour  l'élaboration  du  SLA  (Service  Level  Agreement)  est-elle  clairement  définie  ? 

*  Les  compétences  de  signature  sont-elles  co n t rôlées  ? 

*  Les  annexes  du  contrat  sont-elles  toutes  à  disposition  du  bénéficiaire  de  prestations  ? 

Rapport 

d'évaluation 

*  Le  rapport  a-t-il  été  soumis,  pour  prise  de  position,  à  toutes  Iles  personnes  concernées? 

*  Le  rapport  résume-t-il  les  résultats  et  la  base  de  décision  de  manière  compréhensible  et 
correcte  ? 

*  Les  mesures  planifiées  pour  l'assurance  de  la  qualité  ont-elles  été  exécutées  avec  succès? 

*  L'implémentation  et  l'introduction  sont-elles  subdivisées  en  unités  gérables  ?  Les  priorités 
ont-elles  été  fixées? 
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Point  de  décision:  spécification  du  système 


Résultat 

Critères  d'évaluation 

Concept  de  sûreté 
de  lr information  et 
de  protection  des 
données 

*  Les  données  confidentielles  sont-elles  gérées  à  Laide  de  la  nouvelle  solution? 

*  Existe-t-il  un  scénario  de  secours  ou  à  utiliser  en  cas  de  catastrophe  ?  Les  temps 
d'indisponibilité  maximum  de  la  solution  ont-ils  été  déterminés? 

*  L'architecture  du  système  respecte-elle  les  exigences  en  matière  de  sûreté  de 
l'information  et  de  protection  des  données? 

Concept  de  para¬ 
métrage  et  concept 
des  autorisations 

*  Les  spécifications  de  paramétrage  sont-elles  complètes  et  présentées  avec  le  degré  de 
détail  nécessaire?! Sont-elles  validées  par  les  parties  concernées  ? 

*  Les  autorisations  sont-elles  complètes  et  définies  avec  le  degré  de  détail  nécessaire  ? 

Concept 
d'extension  ou 
concept 
d'intégration  et 
d'interfaces 

*  Les  spécifications  sont-elles  complètes  et  présentées  avec  le  degré  de  détail  nécessaire  ? 
Sont-elles  validées  par  les  parties  concernées? 

*  Le  concept  proposé  est-il  convaincant  et  réalisable  sous  tous  ses  aspects  (moyens 
matériels,  logiciels  informatiques,  organisation,  sûreté  de  l'information,  protection 
des  données)? 

*  Les  concepts  bénéficient-ils  du  soutien  du  département  spécialisé  (bénéficiaire  et 
utilisateur  du  système)? 

*  Les  risques  et  problèmes  de  l'introduction  qui  va  suivre  ont-ils  été  suffisamment  clarifiés? 

*  Le  concept  d'interfaces  contient-il  toutes  les  exigences  ? 

*  L'intégration  dans  le  paysage  des  systèmes  existants  a-t-elle  été  suffisamment  clarifiée 
et  contrôlée? 

*  Les  réservations  des  ressources  nécessaires  pour  la  mise  en  oeuvre  ont-elles  été 
effectuées? 

Concept  de 
processus  et 
d'organisation 

*  Le  concept  de  processus  et  d'organisation  tient-il  compte  de  la  stratégie  d'affaires? 

*  Les  collaborateurs  ont- ils  été  impliqués  dans  le  développement  des  processus? 

*  Le  concept  contient-il  les  processus  de  base  et  de  support? 

*  Les  processus  pe|uvent-ils  être  mis  en  œuvre  dans  l'organisation  existante?  L'évaluation 
des  éventuelles  ressources  supplémentaires  (techniques  ou  humaines)  a-t-elle  été  réalisée? 

*  Les  conséquences  sur  les  processus  existants  et  les  modifications  requises  pour  ceux-ci 
sont-elles  expliquées?  Le  concept  de  processus  permet-il  d'atteindre  les  objectifs  en 
matière  d'efficacité,  de  rentabilité,  de  qualité  et  de  ressources? 

*  Les  processus  sont- ils  décrits  ?  Les  dépendances  entre  eux  ont-elles  été  simulées  ? 

*  Les  indicateurs  des  processus  sont-iils  définis  et  les  instruments  de  gestion  correspon¬ 
dants  présentés? 

*  Le  concept  de  processus  est-il  intégré  dans  l'organigramme  ? 

*  La  forme  d'organisation  ainsi  que  la  structure  fonctionnelle  et  divisionnelle  qui  ont  été 
choisies  sont-elles  cohérentes  et  efficientes  pour  l'organisme? 
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*  Les  collaborateurs  ont-ils  été  impliqués  dans  le  développement  de  la  forme 
d'organisation  ?  Le  résultat  a-t-il  été  communiqué? 

Concept 
d'introduction, 
de  migration  et 
de  formation 

*  Quelle  est  le  scénario  de  migration  ? 

*  Le  concept  d Introduction  bénéficie-t-il  du  soutien  du  département  spécialisé 
(utilisateur  du  système)? 

*  Qu'elle  est  l'analyse  de  risque  pour  l'implémentation,  la  migration  et  l'introduction  ? 

*  Le  concept  de  formation  se  fonde-t-il  sur  les  qualifications  des  personnes  impliquées? 

*  Le  concept  de  migration  indique-t-il  clairement  les  données  existantes  pouvant  être 
reprises  et  celles  qui  ne  peuvent  pas  l'être? 

*  Quelles  sont  les  mesures  prises  pour  les  données  non  reprises  ? 

*  La  reproductibilité  de  la  migration  a-t-elle  été  étudiée  ? 

Concept 
d'exploitation  et 
de  support 


*  L'exploitation  et  l'entretien  du  système  ont-ils  été  conçus  de  manière  suffisamment 
détaillée? 

*  Le  concept  d'exploitation  bénéficie-t-il  du  soutien  du  département  spécialisé  (utilisateur 
du  système)  ? 

*  Quelle  planification  est  prévue  pour  l'organisation  de  support  (y  compris  la  formation)  ? 

*  Le  concept  tient- il  compte  des  exigences  horaires  d'exploitation  des  personnes  impli¬ 
quées? 

*  Quelles  sont  les  scénarii  de  remplacement  ou  en  cas  de  catastrophe  ? 


Point  de  décision:  adaptation  du  système 


Résultat 

Critères  d'évaluation 

Système 

informatique 

*  Les  mises  au  point  ont-elles  été  effectuées  conformément  au  concept  de  paramétrage  ? 

*  Les  normes  et  directives  de  développement  à  appliquer  ont-elles  été  respectées  ? 

*  Une  architecture  spécifique  a-t-elle  été  établie  et  documentée  pour  le  système  ? 

*  Est-ce  que  Iles  programmes  établis  (logiciels  d'interfaces,  migration,  extensions)  couvrent 
les  exigences  envers  le  système  et  l'architecture  de  celui-ci  ? 

*  Les  comptes-rendus  de  tests  et  de  contrôles  confirment- ils  la  maturité  du  système? 

Quelles  sont  les  mesurent  prises  pour  supprimer  les  défauts  constatés? 

Procédé  de 
migration 

*  Les  risques  de  la  migration  vers  le  système  définitif  ont-ils  été  identifiés  et  contrés  par  des 
mesures  adéquates? 

Description  des 
processus  et  de 
l'organisation, 
manuel 

d'organisation 

*  La  stratégie  d'affaires  est-elle  appliquée  dans  la  description  des  processus  et  de  l'organisation  ? 

*  Les  processus,  l'organisation  ainsi  que  les  interfaces  avec  les  processus  voisins  et  les  clients 
sont-ils  décrits? 

*  Les  objectifs  d'efficacité,  de  rentabilité,  de  qualité  et  de  ressources  sont-ils  transposés  dans 
les  indicateurs  de  processus?  Les  instruments  de  gestion  requis  ont-ils  été  mis  en  place? 

*  Les  ressources  nécessaires  sont-elles  connues  et  leur  utilisation  a-t-elle  été  décrite  de  maniè¬ 
re  complète?  Les  responsables  des  processus  ont-ils  été  déterminés? 
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*  Les  collaborateurs  sont-ils  informés  des  modifications  relatives  aux  processus  et  à  la  forme 
d'organisation? 

*  Les  descriptions  de  poste  {avec  les  tâches,  Iles  responsabilités  et  Iles  compétences)  ont-elles 
été  rédigées  de  manière  complète  et  discutées  avec  les  collaborateurs? 

*  Le  manuel  d'organisation  est-il  complet  et  détaillé  de  manière  suffisante? 

*  Le  rythme  de  remaniement  du  manuel  d'organisation  a-t-il  été  fixé? 

Concept  *  Quelles  sont  les  informations  fournies  aux  unités  d'organisation  concernant  le  projet? 

d'introduction 

et 

d'exploitation 


Point  de  décision  de  phase:  feu  vert  à  la  phase  d'introduction 


Résultat 

Critères  d'évaluation 

Rapport 

d'implémen¬ 

tation 

*  Le  rapport  a-t-il  été  soumis  à  toutes  les  personnes  concernées  pour  prise  de  position  ? 

*  Le  rapport  résume-t-il  les  résultats  et  la  situation  de  décision  de  manière  compréhensible  et 
correcte  ? 

*  Les  mesures  AQ  prévues  ont-elles  été  exécutées  avec  succès  ? 

Point  de  décision:  migration  du  système 


Résultat 

Critères  d'évaluation 

Système 

informatique 

*  Les  éléments  et  les  données  devant  faire  l'objet  de  la  migration  ont-ils  été  identifiés  et 
documentés? 

*  La  reproductibilité  de  la  migration  a-t-elle  été  étudiée? 

*  Existe-t-il  une  solution  de  secours  pour  le  cas  où  le  système  migré  comporterait  des  défauts  ? 

Procédure 
de  migration 

*  Le  système  a-t-il  été  migré  dans  un  environnement  de  production  ou,  au  moins,  dans  un 
environnement  analogue  pour  exécuter  les  tests  de  réception? 

*  Les  données  d'application  ont-elles  été  migrées  pour  garantir  les  tests  de  réception  ? 

*  Les  données  d'infrastructure  (utilisateurs,  autorisations,  etc.)  sont-elles  comprises  comme 
partie  intégrante  de  lia  migration  ? 

*  Les  mesures  d'accompagnement  nécessaires  ont-elles  été  établies  pour  les  tests 
de  réception? 

Point  de  décision:  mise  en  service 
(uniquement  adaptation  de  systèmes) 


Résultat 

Critères  d'évaluation 

Concept  de 
formation 

*  Les  utilisateurs  disposent-ils  d'une  formation  et  d'une  expérience  suffisantes  pour  se  servir 
efficacement  du  système  ? 

*  L'assistance  est-elle  réglée  en  cas  de  problème  d'utillisation  et  d'exploitation  ? 

Système 

informatique 

*  Est-ce  que  toutes  données  ont  pu  être  migrées  ? 

Manuel 
de  support 

*  L'organisation  du  support  est-elle  en  place  ? 

SLA 

*  Le  contrat  ou  l'accord  d'exploitation  est-il  conclu  ? 

Manuel 

d'organisation 

*  Toutes  les  conditions  d'ordre  organisationnel  pour  l'exploitation  du  système 
sont-elles  respectées  ? 
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Point  de  décision:  réception  du  système 


Résultat 


Rapports 
d'examen, 
rapports 
de  test 


Critères  d'évaluation 


*  La  réception  du  système  peut-elle  être  effectuée  sur  la  base  des  comptes-rendus  de  test? 

*  Les  défauts  constatés  ont-ils  été  supprimés? 

*  Tous  les  résultats  et  toutes  les  prestations  ont-ils  été  fournis  ? 

*  Tous  les  accords  contractuels  ont-ils  été  remplis  ? 


Concept 

drintroduction 


*  Les  utilisateurs  ont-ils  une  formation  et  une  expérience  suffisantes  pour  utiliser  le  système 
avec  efficacité  ? 

*  Toutes  Iles  personnes  concernées  ont-elles  été  informées  sur  la  nouvelle  répartition 
des  tâches  et  des  compétences? 


*  La  transition  de  l'ancienne  à  la  nouvelle  activité  srest-elle  déroulée  avec  succès  pour 
chaque  utilisateur? 

*  Toutes  les  conditions  organisationnelles  pour  l'exploitation  du  système  sont-elles  en  place? 

*  L'assistance  en  cas  de  problème  d'utilisation  et  d'exploitation  est-elle  réglée? 

*  La  maintenance  du  système  est-elle  réglée?  Un  contrat  de  maintenance  a-t-il  été  conclu? 

*  Le  responsable  du  système  est- il  nommé  et  en  fonction  ? 

*  Les  expériences  de  l'introduction  ont-elles  fait  l'objet  d'une  évaluation  afin  de  pouvoir 
être  réutilisées  au  besoin? 


Point  de  décision  de  phase:  feu  vert  à  la  phase  de  finalisation 


Résultat 

Critères  d'évaluation 

Rapport 

*  Le  rapport  a-t-il  été  soumis,  pour  prise  de  position,  à  toutes  les  personnes  concernées? 

d'introduction 

*  Le  rapport  résume-t-il  Iles  résultats  et  la  base  de  décision  de  manière  compréhensible 

et  correcte  ? 

*  Les  mesures  prises  en  matière  d'assurance  de  la  qualité  ont-elles  été  exécutées  avec  succès  ? 

Check-list  pour  IL  évaluation  des  risques 


Domaine 

Check-list 

Risques  possibles  pour  Ile  projet 

Planification 

*  La  planification  est-elle  actualisée,  adoptée  et  active  (la  mise  en  œuvre  se 

fait-elle  en  conséquence)? 

*  Les  jalons  fixés  pour  mesurer  l'avancement  du  projet,  les  délais  choisis  et 

leur  nombre  sont-ils  adéquats"? 

*  La  planification  est-elle  communiquée  au  fournisseur  et  bénéficiaire  des  pre¬ 

stations  concernées  ? 

Décisions,  ordre  de  mise 

*  Les  décisions  des  organes  du  projet  ainsi  que  des  fournisseurs  et  des  bénéfi¬ 

en  oeuvre  et  contrôle 

ciaires  de  prestations  sont-elles  prises  à  temps? 

des  résultats 

*  Les  décisions  sont-elles  suivies  d'un  ordre  clair  d'application  (avec,  entre 

autres,  les  responsabilités)  et  un  contrôle  des  résultats  est-il  effectué? 

Information 

*  Les  personnes  concernées  par  le  projet  sont-elles  informées  (en  fonction  des 

tâches,  du  calendrier)? 
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Ressources  -  Rentabilité 

Ressources  financières 

*  Les  ressources  financières  ont-elles  été  convenues  par  écrit  avec  Iles  services 
compétents?  Sont-elles  disponibles? 

Ressources  humaines 

*  Les  ressources  humaines  ont-elles  été  convenues  par  écrit  avec  Iles 
services  compétents  ? 

*  Les  ressources  humaines  sont-elles  à  disposition  dans  la  mesure  requise 
(compétences  et  nombre  de  personnes}? 

Besoin  en  ressources 
non  planifiées 

*  Des  ressources  non  planifiées  pourraient-elles  devenir  nécessaires  pour  une 
raison  ou  pour  une  autre? 

Résultat  -  Solution 

Exigences 

*  Les  exigences  du  bénéficiaire  de  prestations  sont-elles  complètes  et 
qualitativement  adéquates  ? 

*  Les  exigences  sont-elles  suffisamment  stables  ? 

*  Existe-t-il  un  concept  clair  pour  la  gestion  des  modifications? 

Complexité  de 
l'application, 
structuration  des  tâches 

*  La  solution  informatique  à  réaliser  est-elle  complexe  ? 

*  La  tâche  (mise  en  oeuvre  des  exigences)  peut-elle  être  structurée  de 
manière  adéquate? 

interfaces  avec  les 
systèmes  environnants 

*  Les  interfaces  avec  les  systèmes  environnants  sont-elles  claires  ? 

*  Y  a-t-il  concordance  au  niveau  du  contenu  et  du  calendrier? 

Intégration  des  utilisateurs  - 

-  Acceptation 

intégration  des  utilisateurs 

*  Les  futurs  utilisateurs  sont-ils  intégrés  dans  le  projet  ? 

Acceptation 
des  utilisateurs 

*  L'acceptation  est-elle  régulièrement  vérifiée  avec  les  utilisateurs  ? 

Fournisseur  de  prestation  -  Entreprise 


Stabilité  de  l'entreprise 

*  Y  a-t-il  des  indices  d'une  mise  en  danger  de  l'existence  de  l'entreprise  ou 
d'un  changement  des  rapports  de  propriété? 

Droits  de  propriété  des 
résultats  (partiels) 

*  L'entreprise  transmet-elle  les  droits  de  propriété  des  résultats  ? 

Transfert  du  savoir-faire 

*  Le  transfert  du  savoir-faire  est-il  assuré  dans  la  mesure  souhaitée  ? 
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8.6.1  Postulats  et  corollaires 

Évidemment  pour  mettre  en  pratique  ces  outils,  méthodes  et  techniques  nous  considérons 
régulièrement  les  postulats  suivants: 

1.  AVOIR  LE  TEMPS 

2.  AVOIR  LES  CONNAISSANCES 

3.  AVOIR  LES  COMPÉTENCES 

4.  AVOIR  LES  MOYENS  (outils,  finances,  ressources,  ressources  compétentes...) 

5.  AVOIR  LA  LÉGITIMITÉ 

6.  AVOIR  LE  SOUTIENT  DE  LA  DIRECTION 
Ces  4  postulats  satisfaits  impliquent  un  corollaire: 

L'OBLIGATION  DE  RÉSULTATS!! 

Nous  y  associons  souvent  le  rappel  des  limites  évidentes  suivantes: 

1.  L'environnement  est  toujours  incertain 

2.  Le  facteur  chance  fait  partie  des  projets 

3.  Une  ressource  est  rarement  disponible  à  100%  (imprévus) 

4.  Aucun  outil  n'est  100%  adapté 

5.  La  gestion  de  projets  n'est  pas  une  science  exacte 
et  le  rappel  des  pièges  suivants: 

-  Penser  qu'on  peut  être  accessoirement  responsable  de  projet 

-  Ne  pas  chercher  les  raisons  pour  lesquelles  on  a  été  nommé  responsable  d'un  projet 

-  Dire  que  "c'est  facile" . . . 

-  Ne  pas  avoir  les  connaissances  (communication,  finance,  logistique,  outils,  lois, 
brevets...) 

-  Ne  pas  écouter  les  collègues  qui  ont  de  l'expérience  métier 

-  Recréer  la  roue  en  termes  de  "méthodes"  et  "outils" 

-  Ne  pas  avoir  formalisé  ses  méthodes  et  en  faire  un  concept 

-  Forcer  une  méthode  inadaptée  à  l'environnement  de  travail 
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-  Ne  pas  se  laisser  le  temps  de  réflexion 

-  Se  rappeler  que  de  petites  variations  ont  un  impact  psychologique  plus  grand  sur  de 
petits  projets  que  sur  des  gros! 

-  Penser  toujours  au  moins  3  coups  à  l'avance  (pour  chaque  tâche  ou  chaque  risque) 


8.6.2  Identification 


Client  need 


Project  Initiation  Request 


Business  Case 


Project  Charter 


La  première  des  cinq  phases,  soit  celle  de  l'identification,  est  sans  aucun  doute  l'une  des  plus 
importantes.  Elle  permet  de  conceptualiser  une  idée  par  une  démarche  logique  qui  nous 
amènera  à  bien  la  maîtriser  tout  en  tenant  compte  de  l'environnement.  La  phase 
d'identification  est  aussi  importante  car  elle  impacte  tout  le  déroulement  du  projet  et  il  devient 
alors  très  difficile  de  faire  des  changements  par  la  suite  sans  impliquer  des  nuisances 
financières  ou  temporelles. 

L'identification  est  normalement  le  rôle  du  Business  Analyst  (selon  le  BABOK)  mais  dans  la 
majorité  des  entreprises  le  responsable  de  projet  cumule  malheureusement  plus  de  rôles 
(fonctions)  et  doit  alors  aussi  s'improviser  expert  dans  ce  domaine. 

Dans  cette  phase  cruciale  pour  tout  projet,  il  y  a  quelques  outils  et  règles  indispensables  qui 
nous  aident  à  bien  identifier  le  projet. 

Avant  d'aborder  ce  sujet  je  souhaite  juste  souligne  l'importance  (comme  le  souligne  le 
BABOK)  d'avoir  un  outil  ou  une  méthode  de  gestion  de  l'information  et  de  la  documentation 
et  ce  afin  d'éviter  les  erreurs  suivantes  (que  l'on  peut  facilement  contourner  avec  un  outil 
comme  Microsoft  SharePoint)  que  je  retrouve  dans  presque  toutes  les  organisations  lorsque 
j'interviens  en  tant  que  consultant: 

•  Centralisation  des  modèles  de  documents  et  fichiers  de  l'entreprise  ainsi  que  des  outils 
informatiques  afin  d'éviter  aux  collaborateurs  dans  différentes  départements  de  perdre 
des  centaines  d'heures  à  recréer  la  roue  en  bricolant  avec  des  macros  ou  du  VBA  pour 
faire  de  la  gestion  de  projets  alors  que  des  progiciels  ont  déjà  été  achetés  ou  qu'une 
SSII  a  déjà  développée  la  solution  requise  il  y  a  plusieurs  années  de  cela... 

•  Centralisation  de  la  documentation  dans  un  système  centralisé  unique  par 
métadonnées  gérées  avec  assignation  automatique  et  unique  de  tout  fichier 
électronique  et  ce  afin  d'éviter  les  copies  de  documents  se  promenant  dans  les  boîtes  e- 
mail  des  collaborateurs  et  que  ne  l'on  sache  plus  quelle  est  la  dernière  version  où  de  ne 
plus  savoir  où  sont  enregistrés  les  documents... 

•  Système  d'approbation  et  de  gestion  des  versions  automatique  de  la  documentation  et 
contrôle  fin  des  accès  aux  informations  afin  d'avoir  une  traçabilité  totale  sur 
l'évolution  de  la  documentation  et  un  système  décisionnel  plus  efficace.... 
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Archivage  des  documents  de  projets  terminés  automatique  ou  semi-automatique 
conformément  aux  standards  internationaux  et  cryptage  des  données  sensibles... 


Parlons  principalement  de  la  Méthode  d'identification  d'un  Projet  (MIP).  Une  fois  bien 
complétée,  la  MIP  devient  un  puissant  outil  de  communication,  puisqu'elle  incorpore  sur 
quelques  pages  l'idée,  le  concept  et/ou  le  mandat  du  gérant  de  projet,  tout  cela  articulé  de 
façon  claire  et  concise  suivant  une  logique  éprouvée.  La  MIP  permettra  de  bien  saisir  la 
problématique  qui  génère  le  projet  afin  d'en  déterminer  le  but  et  les  objectifs.  Elle  permettra 
aussi  d'évaluer  les  risques,  d'élaborer  les  extrants/livrables  et  les  intrants  du  projet  (voir 
définitions  plus  loin),  d'analyser  les  options  potentielles,  tout  cela  dans  le  but  ultime  d'obtenir 
un  mandat  clair,  sans  équivoque  et  très  cristallisé. 

Un  autre  outil  porte  sur  les  dimensions  de  l'environnement,  soit  les  facteurs  externes  et 
internes  pouvant  affecter  en  tout  ou  en  partie  le  projet.  Il  comprend  les  facteurs  suivants: 
physiques  et  environnementaux,  technologiques,  socioculturels,  organisationnels,  politico- 
légaux,  économiques  et  infrastructurels.  C'est  un  ajout  essentiel  et  complémentaire  à  la 
méthode  d'identification  du  projet. 

Grâce  à  cette  excellente  source  d'informations,  les  divers  intervenants  comprendront  sans 
distorsion  le  bien-fondé  du  projet  ainsi  que  le  but  et  les  objectifs  à  atteindre.  Finalement,  le 
tout  aidera  les  instances  décisionnelles  à  prendre  une  décision  éclairée  de  Go/No  Go  pour  la 
suite  ou  le  rejet  du  projet. 

Le  tableau  ci-dessous  présente  les  facteurs  clés  de  succès  que  tout  bon  gestionnaire  devrait 
considérer  avant  d'entreprendre  un  projet. 

8.6.2. 1  Options 

Souvent  un  client  ou  une  entreprise  ou  un  particulier  face  à  un  investissement  ou  à  un  projet 
va  comparer  plusieurs  alternatives  ou  solutions  entre  elles.  Il  est  bien  évidemment  possible  de 
faire  un  choix  au  bolomètre  (mais  alors  à  quoi  cela  sert-il  de  faire  un  cursus  universitaire  si 
c'est  pour  utiliser  des  méthodes  d'enfants  de  6  ans  par  la  suite  en  entreprise. . .  ou  encore 
d'utiliser  le  classique  système  des  notes  avec  pondérations  empiriques  des  critères  qui 
équivaut  la  méthode  de  travail  de  tout  adolescent  moyen. 

Une  méthode  un  peu  plus  élaborée  que  l'assignation  de  notes  avec  des  poids  empiriques 
consiste  à  utiliser  les  Maison  de  la  qualité  Six  Sigma  que  nous  verrons  un  peu  plus  loin  (voir 
page  249)  mais  cela  reste  toutefois  très  enfantin  et  peu  scientifique  (donc  pas  rigoureux  du 
tout!). 

Un  méthode  décisionnelle  déterministe  utilisée  au  plus  haut  niveau  des  gouvernements  et 
entreprises  est  l'APH  qui  est  une  technique  d'analyse  décisionnelle  multicritère  ("Multi 
Criteria  Decision  Making"  (MCDM)  en  anglais). 

Nous  savons  que  les  systèmes  de  votes  traditionnels  ou  de  notes/rangs  ne  peuvent  pas  être 
utilisés  dans  le  cadre  de  décisions  complexes  multicritères  et  multi-niveaux  car  ces  derniers  ne 
prennent  trivialement  pas  en  compte  le  poids  d'importance  associés  aux  composants.  De  plus, 
même  si  un  poids  était  affecté  le  problème  résider  dans  le  choix  d'une  valeur  empirique  de  ce 
dernier  ce  qui  rend  l'approche  totalement  non  scientifique  et  ouvre  la  porte  à  des  débats 
interminables  dans  la  pratique. 
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Pour  présenter  la  technique  de  l'APH  il  nous  semble  pertinent  de  commencer  avec  un  exemple 
d’analyse  naïve  d’une  somme  de  scores  (notes): 


Critère/ Alternative 

Choix  de  X 

Choix  de  Y 

Choix  de  Z 

Plage 

Facteur  A 

1 

4 

5 

0-5 

Facteur  B 

20 

70 

50 

1-100 

Facteur  C 

-2 

0 

1 

-2  à +2 

Facteur  D 

0.4 

0.75 

0.4 

Oà  1 

Somme 

19.4 

74.75 

56.4 

Score  normalisé 

12.9% 

49.7% 

37.5% 

Cependant,  vous  remarquerez  que  la  plage  de  valeurs  pour  chaque  facteur  du  produit/projet 
n’est  pas  la  même.  Il  est  alors  tout  à  fait  injuste  de  résumer  toutes  les  valeurs  de  plusieurs 
critères  et  comparer  le  résultat.  Il  est  clair  que  le  facteur  B  est  dominant  parce  que  la  gamme  a 
une  valeur  plus  élevée.  Pour  être  juste,  nous  pouvons  proposer  au  moins  deux  solutions 
triviales: 


1.  Au  lieu  d’utiliser  des  valeurs  arbitraires  pour  chaque  facteur,  nous  positionnons 
juste  le  choix  pour  chaque  facteur:  la  valeur  de  rang  plus  petit  est  plus 
préférable  que  celle  de  rang  supérieur  (c’est  psychologie  par  rapport  à  l’usage 
quotidien  de  la  majorité  des  humains). 

2.  Nous  transformons  la  valeur  du  score  de  chaque  facteur  en  fonction  de  la 
valeur  de  plage  de  sorte  que  chaque  facteur  aura  la  même  étendue 
(normalisation  des  scores). 

Essayons  les  deux  solutions  en  commençant  par  la  première: 


Critère/Alternative 

Choix  de  X 

Choix  de  Y 

Choix  de  Z 

Facteur  A 

3 

2 

1 

Facteur  B 

3 

1 

2 

Facteur  C 

3 

2 

1 

Facteur  D 

2 

1 

2 

Somme 

11 

6 

6 

Score  normalisé 

26.09% 

36.96% 

36.96% 

où,  puisque  la  plus  petite  valeur  de  rang  est  la  meilleure,  nous  avons  renormalisé  les  codes  de 
la  façon  logique  suivante: 


1.  Comme  la  somme  de  tous  les  rangs  est  toujours  égale,  soustraire  du  total  des  rangs  RT 

la  somme  des  rangs  d’une  colonne  RCi  a  pour  effet  automatiquement  de  lui  donner 

l’importance  inverse  (effectivement  si  la  somme  totale  des  rangs  vaut  23  comme  ci- 
dessus  alors  23-6=17  alors  que  23-11=12  donc  nous  avons  bien  l’effet  recherché). 
Nous  avons  alors  la  somme  des  rangs  normalisée 

SRNi  =  RT  —  RCi 

2.  Nous  voulons  un  pourcentage,  dès  lors  il  est  naturel  d’écrire: 
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RT  —  R^-  R^- 

%SRm  =  — - —  =  1  c' 


/?T 


3.  Le  problème  de  ce  dernier  calcul  c'est  qu'il  donne  systématiquement  sommé  pour 
toutes  les  colonnes  200%.  Il  faut  alors  le  multiplier  par  0.5  tel  que  au  final: 


%SRm  =  0.5 


C  d  "N 

1  Rci 


V 


R 


T  J 


Maintenant  il  est  important  de  remarquer  que  le  fait  de  travailler  avec  les  rangs  ne  donne  plus 
le  même  résultat  que  dans  le  tableau  antéprécédent.  Effectivement,  les  choix  F  et  Z  deviennent 
indifférents  et  donc  nous  avons  perdu  de  l'information! 

Raison  pour  laquelle  est  il  recommandé  de  travailler  sur  les  scores  plutôt  que  les  rangs  car  non 
seulement  travailler  sur  les  rangs  peut  amener  à  des  égalités  qui  n'avaient  pas  lieu  d'être  mais 
dans  certains  cas  cela  inverse  même  le  range  final  de  certains  éléments  d'un  choix  (nous 
parlons  alors  "d'effet  d'inversion  de  rang  par  les  scores"). 

Maintenant  voyons  l'effet  qu'aurait  de  normaliser  les  scores  du  premier  tableau  entre  0  et 
100%  en  utilisant  simplement  une  règle  de  trois  (après  décalage  des  scores),  le  tableau 
suivant: 


Critère/ Alternative 

Choix  de  X 

Choix  de  Y 

Choix  de  Z 

Plage 

Facteur  A 

1 

4 

5 

0-5 

Facteur  B 

20 

70 

50 

1-100 

Facteur  C 

-2 

0 

1 

-2  à +2 

Facteur  D 

0.4 

0.75 

0.4 

Oà  1 

Somme 

19.4 

74.75 

56.4 

Score  normalisé 

12.9% 

49.7% 

37.5% 

Devient  alors: 

Le  calcul  est  clairement  un  peu  plus  compliqué  qu'avec  les  rangs  mais  nous  avon  un  résultat 
meilleur  dans  le  sens  que  la  conclusion  n'est  pas  changée. 

Maintenant  voyons  une  version  naturellement  plus  évoluée  inspirée  des  portefeuilles 
financiers  incluant  des  poids  aux  critères.  Évidemment  le  résultat  de  l'exemple  qui  suit  ne  sera 
plus  comparable  aux  précédents. 

Donc  considérons  le  tableau  de  poids  suivant: 


Facteur  A 

Facteur  B 

Facteur  C 

Facteur  D 

Somme 

Poids 

6 

2 

2 

1 

11 

Poids  relatifs 

54.5% 

18.2% 

18.2% 

9.1% 

100% 

Notre  tableau  des  scores  normalisés  devient  alors: 


Critère/ Alternative 

Poids 

Choix  de  X 

Choix  de  Y 

Choix  de  Z 

Facteur  A 

54.5% 

0.109 

0.436 

0.545 
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Facteur  B 

18.2% 

0.035 

0.127 

0.090 

Facteur  C 

18.2% 

0.000 

0.091 

0.136 

Facteur  D 

9.1% 

0.036 

0.068 

0.036 

Somme 

100% 

0.180 

0.722 

0.808 

Score  normalisé 

10.5% 

42.2% 

47.2% 

Bon  ce  techniques  élémentaires  décisionnelles  ayant  été  présentées  passons  maintenant  à 
l'APH  à  proprement  parlé  qui  a  une  approche  complément  différente! 

Remarque:  Signalons  que  l'auteur  de  cette  méthode  (Thomas  Saaty)  a  édité  un  logiciel  qui 
permet  d'automatiser  des  procédures  complexes  de  décision  basées  entre  autres  sur  sa 
méthode  et  qu'il  est  possible  de  retrouver  à  l'adresse  suivante  http://www.superdecisions.com. 

L'approche  de  l'APH  se  veut  déjà  être  très  mathématique.  Dès  lors  intuitivement  nous 
pouvons  déjà  nous  dire  que  les  scores  normalisés  sont  en  réalité  les  composantes  d'un  vecteur 
de  poids  de  préférence  dont  la  somme  vaut  100%: 


w  = 


Ensuite  la  deuxième  idée  est  de  comparer  via  une  matrice  pour  un  facteur  donné  les  choix  qui 
sont  à  disposition  (dans  le  but  évidemment  d'avoir  une  approche  utilisant  la  puissance  de 
l'algèbre  linéaire).  Par  exemple  en  reprenant  nos  tableaux  ci-dessus  et  en  focalisant  sur  la 
Facteur  A,  nous  aurions: 


Facteur  A 

Choix  A 

Choix  B 

Choix  C 

Choix  A 

1 

? 

? 

Choix  B 

? 

1 

? 

Choix  C 

? 

? 

1 

Les  valeurs  (scores)  de  la  diagonale  sont  évidentes  car  chaque  choix  ne  peut  pas  être  préféré  à 
lui-même  que  dans  une  relation  autre  qu'une  égalité  unitaire  stricte. 

Déjà  deux  questions  peuvent  se  poser  à  ce  niveau: 

Ql.  Sachant  que  les  scores  (parfois  appelés  "stimulis")  doivent  avoir  une  forme  de  symétrie, 
combien  de  scores  en  fonction  du  nombre  de  choix  n  devra  faire  un  "juge". 

Q2.  Quelle  échelle  de  score  ("stimuli")  choisir  et  quelle  relation  de  symétrie  (par  exemple 
entre  Choix  B-Choix  A  et  Choix  A-Choix  B  car  si  nous  devons  choisir  l'un,  l'autre  doit 
découler  automatiquement) 

Pour  répondre  à  la  première  question  nous  pouvons  construire  un  simple  tableau  (il  s'agit  donc 
simplement  du  nombre  de  cas  au-dessous  ou  respectivement  en  dessous  de  la  diagonale  de  la 
matrice  de  préférence): 


Nbr.  de  choix 

1 

2 

3 

4 

5 

6 

7 

n 

Nbr.  de 
comparaisons 

0 

1 

3 

6 

10 

15 

21 

n{n- 1) 

2 
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Pour  répondre  à  la  deuxième  question  il  vaut  mieux  se  mettre  dans  la  peau  d'un 
mathématicien,  ingénieur  ou  statisticien.  Déjà  sachant  que  l'égalité  est  logiquement  "1"  il 
serait  mal  venu  de  prendre  l'ensemble  des  réels  avec  des  valeurs  négatives  pour  la  réciproque 
sachant  que  dans  ce  cas  l'égalité  devrait  être  zéro  et  non  plus  1.  Ceci  dit  prendre  une  matrice 
de  préférence  dont  la  diagonale  serait  des  zéros  reviendrait  à  utiliser  des  techniques  propres  au 
Data  Mining  puisque  cela  revient  à  avoir  une  matrice  des  distances.  Mais  le  problème  des 
matrices  des  distances  dans  le  contexte  qui  nous  intéresse  ici  c'est  que  les  composantes  sont 
symétriques  et  dans  le  cas  des  préférences  cela  n'est  pas  de  sens! 

Donc  notons  la  matrice  carrée  des  scores  de  la  manière  suivante: 


A  =  (aij) 


Une  piste  serait  de  se  dire  que  puisque  nous  avons  un  vecteur  des  poids  w ,  il  faudrait  opérer 
entre  la  matrice  des  préférences  et  ce  vecteur  des  poids  d'une  manière  ou  d'une  autre.  Or,  en 
pensant  au  fait  que  dans  le  domaine  des  Statistiques  nous  retrouvons  souvent  le  concept  de 
vecteur  et  de  valeur  propre  alors,  le  choix  de  la  multiplication  s'impose  de  façon  assez 
naturelle: 


1  al2  •••  aln 

ü2\  1  ■“  a2n 

an\  an2  ann 


1  al2 

a2l  1 


a 


1  n 


*2  n 


Wi 


\ 


a 


ni 


a 


n  2 


\WnJ 


Maintenant,  le  fait  d'avoir  pris  la  multiplication  nous  donne  une  piste  sur  le  choix  des 
composantes  de  la  matrice  des  préférences.  Effectivement,  si  nous  prenons: 


(N 

T— |  (N  . 

S 

1 _ 

■■  a\n 

fw,) 

w1 

/  Vq 
/  vq 

Wj  /  w2 

w2/w2  • 

■■  vq 

/  W 

n 

/  W 

n 

?"  ••• 

fwA 

••  a2n 

= 

w2 

••  w2 

=  n 

_anl  an2 

••  1 

KWny 

w 

L  n 

/  Wj 

wn/w2  ■ 

••  wn 

/  W 
n  J 

KWn, 

VWny 

nous  avons  une  relation  entre  un  vecteur  propre  et  une  valeur  propre  entière  via  une  matrice 
(application  linéaire)  dont  les  composantes  sont  les  préférences.  Remarquez  aussi  au  passage 
que  la  somme  des  valeurs  d'un  colonne  i  est  égale  à  1  /  vq .  Et  si  nous  observons  bien  nous 
avons  en  réalité: 


wl  /  vq  vq  /  w2  • 

1 - 

(wA 

1  al2 

••  «1  n 

w2  /  wl  w2  /  w2  • 

••  w2lwn 

= 

1  /  al2  1 

••  a2  n 

1 

J 

=7 

J 

i 

i _ 

Kwny 

_l/aln  1  /a2n  ■ 

■■  1 

Wj  1 

=  n 

KWny 

KWny 

Ingénierie  de  Gestion  de  projets 


236/547 


Ce  qui  revient  à  avoir  un  problème  aux  vecteurs  et  valeurs  propres  (cf.  chapitre  d' Algèbre 
Linéaire): 


(A  -  ni)  w  =  0 

Étant  donné  le  polynôme  caractéristique  suivant  (cf.  chapitre  d’ Algèbre  Linéaire): 


det  (A  -  AI2)  - 


ûfjj  A 


a- 


21 


“12 

a22  ~  ^ 


-A2  -  (flu  +  a22  )  A  +  (üti  1^22  -  a21a12  ) 


tr(A) 


deHii) 


ou  encore  suivant  (cf.  chapitre  d' Algèbre  Linéaire): 


1 - » 

1 

a12 

üj3 

det  (  A -  Al2  )  - 

r— 1 

T4 

y 

a22  ~  ^ 

ü23 

Ü31 

a32 

A 

-  -  A3  +  (üfj  J  +  a2 2  +  Ü33)  A?  -  (ü!iil233  +  &22a33  +  Ü1 1^22  _  a32a23  ~  a12a21  ~  a3\a\3) ^ 
+  (^11^22^33  ~fll  1^32^23  "^12^21^33  +  a31fl23a12  a13a21a32  "^13^31^22) 

ïîcü 


Au  vu  de  la  construction  de  la  matrice  des  préférences,  nous  voyons  alors  que: 

det  (A  -  AI  2  )  =  A2  - 2/1 +  1-1  =  A2 -2/1  =  0 


et  donc  il  n'y  a  qu'une  seule  valeur  propre,  elle  est  entière  et  vaut  bien  A-n-  2 .  Nous  disons 
alors  que  toute  matrice  carrée  réciproque  de  dimensions  2  est  consistante. 

Passons  à  une  dimension  supérieure: 

det  (A  —  AI ^  )  =  — A  '  +  3  A  +  (l  —  1  —  1  +  6(31^23^12  ^13^21^32  —  l) 

3  2 

—  A  l  3,1*  “H  d^^d2 36(2  — t  ^13^21^32  2  —  ô 

Nous  disons  dans  ce  cas  que  toute  matrice  carrée  réciproque  de  dimensions  3  n’est  pas 
nécessairement  consistante.  Pour  que  cela  soit  le  cas,  il  faudrait  que: 

d^-^d^^d^^  “I-  ^3^21^32  2  —  0 

et  seulement  dans  ce  cas  nous  aurons  une  seule  valeur  propre  A  =  n  =  3 .  Remarquez  que  si 
nous  écrivons  cette  dernière  relation  sous  la  forme: 

djka,jdkl  +  akjClikaji  -  2  =  ° 


Alors  si: 


ajkau  =  au 
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la  matrice  est  consistante.  Nous  verrons  un  peu  plus  loin  l'impact  pratique  qu'à  cette  dernière 
égalité. 

Il  faut  bien  évidemment  au  besoin  normaliser  le  vecteur  propre  afin  que  la  somme  des  poids 
de  préférence  soit  unitaire  tel  que: 


w 


Donc  cela  nous  amène  à  avoir  si  nous  jugeons  notre  préférence  sur  une  échelle  du  type 
suivant  pour  nos  trois  choix  du  Facteur  A: 

[Choix  A]  98765432123456789  [Choix  B] 

[Choix  A]  98765432123456789  [Choix  C] 

[Choix  B]  98765432123456789  [Choix  C] 

et  en  faisant  bien  attention  à  mettre  les  préférences  directes  dans  la  partie  supérieure  de  la 
matrice  et  l'inverse  dans  la  partie  inférieure  (sinon  quoi  le  vecteur  propre  ne  sera  pas  le  même 
et  in  extenso  les  poids  aussi!): 


Facteur  A 

Choix  A 

Choix  B 

Choix  C 

Choix  A 

1 

1/3 

5 

Choix  B 

3 

1 

7 

Choix  C 

1/5 

1/7 

1 

Dans  l'exemple  ci-dessus  les  préférences  sont  consistantes  car  si  B  est  préféré  à  A  (6  ^  4  )  et 
A  est  préféré  à  C  (  A  y  C  ),  nous  devrions  alors  avoir  logiquement  B  y  C  et  qui  est  bien  le 
cas  ici.  Dans  le  cas  contraire  nous  disons  que  les  choix  sont  inconsistants.  Cette  consistance  se 
résume  par  la  relation  vue  plus  haut  où  dans  le  cas  idéal  nous  devrions  avoir: 

ajkaij  =aik 

Soit  pour  être  consistant  nous  allons  nous  intéresser  à  la  combinaison  faisant  intervenir  les 
choix  C  et  B,  c'est-à-dire: 


aj3a2  j  ~  a23  üACaBA  —5-3  —  15 


Donc  pour  être  totalement  consistants  nous  devrions  avoir  pour  aBC  la  valeur  de  15  mais  ce 

n'est  pas  quelque  chose  que  nous  pouvons  exiger  pratiquement  parlant.  Cependant  l'écart  à  la 
consistance  parfaite  va  générer  des  valeurs  propres  supplémentaires  autre  que  l'unique  valeur 
propre  qui  vaut  n  lorsque  la  consistance  est  parfaite.  Dès  lors,  une  mesure  possible  de 
l'inconsistance  est  la  moyenne  des  valeurs  propres  autres  que  la  principale: 


1 


n  - 1 


2A 


i= 2 


qui  en  cas  de  consistance  parfait  est  donc  nul. 
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Pour  simplifier  le  calcul  de  CI,  nous  allons  utiliser  le  fait  que  nous  avons  démontré  dans  le 
chapitre  d' Algèbre  Linéaire  que  la  trace  d'une  matrice  est  égale  à  la  somme  de  ces  valeurs 
propres.  Donc  nous  pouvons  écrire: 

n  n  n 

tr(A)  —  n  —  ^  ’t  A-  —  Amax  +  ^  ^  H  Amax 

(=1  i=2  i=2 

D'où  un  choix  possible  pour  mesure  la  consistance: 


-1 


n  - 1 


Mais  par  tradition  nous  prenons  la  valeur  négative  de  cette  relation  comme  définition  du 
"critère  de  consistance": 


CI  = 


A„ 


-n 


n- 1 


Donc  ci-dessus,  par  exemple,  le  choix  B  a  été  noté  3  par  rapport  au  choix  A  (donc  B  est 
préféré  à  A).  Déterminé  le  poids  des  préférences  revient  donc  à  un  problème  de  vecteurs  et 
valeurs  propres: 


f 

"  1 

1/3 

5" 

A 

(  ™  \ 
W] 

( 

"  i 

1/3 

5" 

(Wl) 

-ni 

1 

-1 

3 

1 

7 

w2 

— 

n 

3 

1 

7 

w2 

V 

1/5 

1/7 

1 

J 

K 

1/5 

1/7 

1 

) 

KWn, 

où  il  ne  faut  pas  oublier  que  multiplier  une  matrice  avec  un  scalaire  revient  à  multiplier  les 
valeurs  propres  par  ce  même  scalaire  (et  non  directement  les  composantes  des  vecteurs 
propres).  Raison  pour  laquelle  que  nous  cherchions  les  vecteurs  propres  de  la  matrice  des 
préférences  ou  de  la  matrice  des  préférences  normalisée  par  1/n  les  vecteurs  propres  seront  les 
mêmes! 

Donc  en  faisant  des  calculs  à  la  main  ou  par  ordinateur  (cf.  chapitre  d' Algèbre  Linéaire),  nous 
obtenons: 


fV 

'  0.397989  " 

"27.895%^ 

w  = 

w2 

= 

0.914031 

=>  WN  = 

64.911% 

KWny 

v0.1012818  J 

v07.192%y 

Mais  les  trois  valeurs  propres  ne  sont  pas  nulles  car  nous  avons: 

Al  =  3.06488,  ^  =-0.324438  +  0.447702/,  ^  =  -0.0324438-0.447702* 


et  nous  savons  que  cela  vient  du  fait  de  la  faible  non  consistance  de  notre  matrice  des 
préférences.  Nous  avons  alors  pour  critère  de  consistance: 


CI  = 


3.06488-3 
3— ï 


0.03244 
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OK  c'est  proche  de  0  donc  a  priori  c'est  une  bonne  consistance.  Mais  pour  avoir  un  jugement 
scientifique  sur  cette  valeur  le  mieux  reste  encore  de  faire  des  milliers  de  simulations  de 
matrices  avec  des  jugements  tirés  au  hasard  consistants  ou  non  et  de  calcul  leur  consistance 
moyenne.  Ainsi  d'après  l'article  original,  avec  50'000  simulations  nous  obtenons  pour  chacune 
des  matrices  de  préférence  de  taille  n  un  indice  aléatoire  de  consistance  (noté  RI  pour 
"random  index"): 


n 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

RI 

0 

0.52 

0.89 

1.11 

1.25 

1.35 

1.40 

1.45 

1.49 

Remarque:  Dans  la  pratique  il  est  conseillé  de  ne  pas  dépasser  n  valant  7  car  au-delà  l'esprit 
humain  à  de  la  peine  à  conceptualiser  rapidement. 

Donc  dans  le  cas  de  notre  exemple,  nous  avons  la  ratio  de  consistance: 


a  0.03244 
RI  ~  0.52 


0.0623 


Et  évidemment  plus  ce  ratio  est  petit  (dans  le  sens  inférieur  à  l'unité!)  mieux  c'est.  Il  est 
d'usage  dans  la  pratique  de  dire  que  si  ce  ratio  est  inférieur  à  0. 1  alors  l'inconsistance  est 
acceptable  (et  donc  la  consistance  est  bonne). 

Voyons  maintenant  un  cas  multi-niveaux  de  l'APH. 

Exemple: 

Considérons  que  nous  devons  choisir  parmi  4  voitures  sur  la  base  de  3  critères: 


Supposons  que  la  matrice  des  préférences  soit  trois  premiers  critères  techniques  soit: 


Technique 

Style 

Fiabilité 

Consommation 

Style 

1 

1/2 

3 

Fiabilité 

2 

1 

4 

Consommation 

1/3 

1/4 

1 

En  faisant  les  mêmes  calculs  que  plus  haut  ou  en  s'aidant  d'un  logiciel,  nous  obtenons: 
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Maintenant  nous  faisons  le  deuxième  niveau,  c'est-à-dire  la  matrice  de  préférence  des  voitures 
pour  le  style  (comparaison  par  paire  des  styles  donc. . 


Voiture  Style 

Civic 

Saturn 

Escort 

Clio 

Civic 

1 

1/4 

4 

1/6 

Saturn 

4 

1 

4 

1/4 

Escort 

1/4 

1/4 

1 

1/5 

Clio 

6 

4 

5 

1 

Et  nous  faisons  de  même  pour  les  deux  autres  critères  pour  obtenir: 


Il  s'agit  maintenant  de  combiner  ces  deux  niveaux!  Pour  cela  il  semble  intuitif  de  faire  la 
multiplication  matricielle  (pondération)  suivante: 


'0.1160 

0.3790 

0.3010' 

'0.3060' 

Civic 

'0.3196' 

0.2470 

0.2900 

0.2390 

0.5584 

0.2720 

Saturn 

0.0600 

0.0740 

0.2120 

0.1220 

0.0940 

Escort 

0.5770 

0.2570 

0.2480 

_0.3280_ 

clio 

Donc  la  Clio  sort  gagnante  de  cette  APH! 
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8. 6.2.2  Niveau  de  criticité 

Je  recommande  chaudement  d'être  réaliste  par  rapport  la  phase  d'identification  (et  ce  qui 
s'ensuite)  relativement  à  l'amplitude  de  l'investissement  du  projet  que  de  sa  criticité. 
Effectivement,  nous  pouvons  dire  que  pour  des  projets  en-dessous  de  300'000€  des  méthodes 
Agiles  sont  bien  adaptées  et  il  est  inutile  de  sortir  un  rouleur  compresseur  pour  écraser  une 
mouche.  Mais  la  finance  n'est  pas  le  seul  critère  bien  évidemment,  pour  cette  raison  la  norme 
DO- 178  (bien  qu'elle  normalement  dédiée  au  développement  logiciel)  peut  être  une  base  de 
travail  pour  le  choix  du  niveau  de  détails  de  la  phase  d'identification  des  moyens  mis  en 
oeuvre  pour  suivre  le  projet. 

Selon  cette  norme,  et  en  faisant  un  parallèle  avec  la  gestion  de  projets  générale,  nous  avons  5 
niveaux  de  criticité  de  projets  définis  comme  suit: 

•  Niveau  A:  Un  défaut  du  livrable  ou  sous-livrable  peut  provoquer  un  problème 
catastrophique  pour  le  client  (faillite,  décès,  impact  social  non  localisé,  etc.) 

•  Niveau  B:  Un  défaut  du  livrable  ou  sous-livrable  peut  provoquer  un  problème  majeur 
entraînant  des  dégâts  sérieux  pour  le  client  (absence  de  bénéfice  pendant  une  période, 
réputation  entachée,  perte  de  clients,  licenciements,  parution  dans  les  médias,  etc.) 

•  Niveau  C:  Un  défaut  du  livrable  ou  sous-livrable  peut  provoquer  un  problème  sérieux 
entraînant  un  dysfonctionnement  des  procédures  du  travail  pour  le  client  (arrêt  de  la 
production  temporaire,  défauts  de  fabrications,  etc.) 

•  Niveau  D:  Un  défaut  du  livrable  ou  sous-livrable  peut  provoquer  un  problème 
pouvant  perturber  temporairement  les  procédures  de  travail  du  client  causant  quelques 
pertes  négligeables  par  rapport  à  son  volume  d'affaires. 

•  Niveau  E:  Un  défaut  du  livrable  ou  sous-livrable  étudié  peut  provoquer  un  problème 
sans  effet  pour  le  client. 

Ces  5  niveaux  sont  aussi  appelés  "niveaux  DAL"  (Development  Assurance  Level)  et  peuvent 
être  établis  grossièrement  pour  par  une  étude  de  sûreté  de  fonctionnement. 

Pour  ce  qui  est  documents  à  fournir  concernant  cette  norme,  nous  avons  (toujours  après 
généralisation  à  la  gestion  de  projets  en  général): 

Phase  de  planification: 

•  Plan  des  aspects  du  livrable  relatifs  à  la  certification:  en  particulier  ce  document 
précise  le  niveau  de  criticité  retenu,  et  par  quels  moyens  on  prévoit  de  remplir  les 
objectifs  des  normes  ED-12C  /  DO-178C 

•  Plan  de  développement/fabrication  du  livrable 

•  Plan  de  vérification  du  livrable 

•  Plan  de  gestion  de  configuration  du  livrable 

•  Plan  d'assurance  qualité  du  livrable 

•  Règles  de  spécifications  du  livrable 

•  Règles  de  conception  du  livrable 

•  Règles  d'utilisation  du  livrable 
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Concernant  le  processus  de  développement/fabrication  proprement  dit  : 

•  Spécifications  des  exigences  du  livrable 

•  Description  de  la  conception  du  livrable 

Concernant  le  processus  de  vérification: 

•  Cas  et  procédures  de  vérification  du  livrable 

•  Résultats  de  la  vérification  du  livrable: 

o  Résultats  de  tests  unitaires 
o  Résultats  de  tests  d'intégration 
o  Résultats  de  tests 
o  Analyse  de  la  couverture  du  livrable 
o  Revue  de  chaque  document  du  livrable 

Concernant  le  processus  de  gestion  de  configuration: 

•  Index  de  la  configuration  du  livrable 

•  Index  de  l'environnement  du  cycle  de  vie  du  livrable 

Concernant  le  processus  d'assurance  qualité: 

•  Enregistrements  relatifs  à  la  qualité 

•  Compte-rendu  de  revue  de  conformité 

•  Résumé  des  travaux  réalisés 

Il  est  donc  aisé  de  comprendre  pourquoi  à  partir  d'un  certain  niveau  de  criticité  de  projet  ou 
d'investissement  financier,  il  n'est  plus  possible  de  s'improviser  seul  responsable  de  projets 
mais  il  faut  être  entouré  d'une  équipe  d'experts  qui  va  assez  rapidement  explosé  les  coûts. 
Raison  pour  laquelle  en-dessous  de  ~300'000€  nous  considérons  souvent  qu'un  seul 
responsable  de  projet  (pour  des  "micro-projets"  souvent  de  Niveau  D  et  E)  non  expert  est 
suffisant. 


8.6.23  M.I.P 

Revenons  donc  à  la  méthode  d'identification  de  projet  (MIP)  en  l'appliquant  à  un  projet  de 
rénovation.  Il  s'agit  de  bien  identifier  notre  projet  pour  qu'il  réponde  clairement  à  nos  attentes. 
L'étape  "élaboration  de  la  MIP"  consiste  en  premier  lieu  à  comprendre  la  problématique  et  les 
besoins  qui  génèrent  ce  projet,  et  à  structurer  le  concept  ou  l'idée  par  une  approche 
méthodique  d'identification. 


Le  document  MIP  (appelé  également  PDP  pour  "Plan  directeur  du  Projet"  ou  encore  "Mandat 
de  projet",  ou  encore  "Charte  de  projet")  que  vous  pouvez  utiliser  lors  de  l'identification  de 
votre  projet  contient  d'abord  typiquement  les  informations  suivantes: 
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1.  Le  titre  du  projet 

2.  Le  responsable  de  l'élaboration  (gérant  de  projet)  -  appelé  aussi  "entreprise 
adjudicataire" 

3.  Le  promoteur/mandant  (organisation/division/département)  du  projet  appelé  aussi 
parfois  "bénéficiaire  de  prestations". 

4.  Le  mandataire  (prestataire)  qui  donne  le  mandat  abrégé  parfois  DO  pour  "donneur 
d'ordres"  et  appelés  aussi  quelques  fois  "fournisseur  de  prestations". 

5.  L'objectif  et  le  but  du  projet. 

6.  Les  différents  responsables  et  intervenants  du  projet  (organigramme  du  projet) 

7.  Le  type  de  contrat  qui  va  être  utilisé 

8.  La  date  d'élaboration  de  la  MIP 


Ensuite,  viennent  (outres  les  analyses  statistiques  du  projet  qui  sont  hors  contexte  de  ce 
cours),  le  sommaire  exécutif,  la  problématique  du  projet,  la  description,  identification 
des  options,  les  intrants  et  extrants,  l'évaluation  des  risques,  la  stratégie  de  réalisation, 
dimensions/contraintes  de  l'environnement,  etc. 


How  it  was  supported  What  the  customer  really 

needed 


Figure  19  Ce  qu'une  bonne  analyse  fonctionnelle  permet  d'éviter 
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Mais  pourquoi  devrais-je  rédiger  tout  mon  projet?  N'est-ce  pas  une  perte  de  temps? 

Si  vous  rédigez  le  projet  de  façon  structurée  et  détaillée,  vous  serez  sûr  qu'aucun  aspect  n'aura 
été  oublié.  La  structure  est,  par  elle-même  une  check-list  garantissant  la  qualité  de  vos  projets. 


8. 6. 2. 3.1  Sommaire  exécutif 


Le  sommaire  exécutif  se  veut  la  radiographie  du  projet.  En  une  seule  page,  vous  devez 
expliquer  aux  autorités  compétentes  le  bien-fondé  de  votre  projet  afin  d'obtenir  l'approbation 
nécessaire  pour  poursuivre  la  planification  de  ce  dernier.  Celui  devrait  comprendre 
principalement  le  but,  les  objectifs,  l'option  choisie,  le  budget  préliminaire,  les  grands  jalons 
ainsi  que  les  biens  livrables. 

À  remarquer  que  la  formulation  d'objectifs  n'est  pas  toujours  aussi  évidente  qu'elle  ne  le  paraît 
à  première  vue.  Raison  pour  laquelle  un  certain  nombre  de  gens  ne  se  fixent  jamais  des 
objectifs  précis.  Leur  existence,  l'image  d'un  bateau  ballotté  par  les  vagues  et  poussé  de-ci  de¬ 
là  par  des  vents  capricieux,  est  caractérisée  par  le  laisser-aller  et  le  laisser-vivre.  Ils  prennent 
les  choses  comme  elles  viennent  avec  philosophie.  C'est  la  dispersion,  l'action  sans  but,  le 
contraire  de  l'efficience.  Un  responsable  de  projets  sans  plans  est  donc  comme  un  navire  sans 
gouvernails... 

Afin  de  formuler  les  objectifs  sous  une  forme  valable,  le  recours  à  la  technique  SMART  est 
parfois  approprié. 

SMART  signifie: 

•  Spécifique:  Un  objectif  ne  peut  être  formulé  de  manière  vague  et  générale,  mais  doit 
être  défini  de  manière  rigoureuse  et  précise. 

•  Mesurable:  Afin  de  pouvoir  examiner  si  les  objectifs  sont  atteints  (en  délais,  coûts  et 
qualité),  ceux-ci  doivent  être  mesurables.  Des  normes  doivent  être  établies.  Il  est 
d'ailleurs  important  lors  des  entretiens  de  fonctionnement  et  d'évaluation  de  pouvoir 
mesurer  de  manière  objective  si  les  objectifs  visés  ont  été  atteints.  Cette  mesure  peut 
se  traduire  bien  évidemment  sous  la  forme  classique  de  notions  de  quantité,  de  qualité, 
de  temps,  d'argent. 

•  Acceptable:  Les  objectifs  doivent  être  acceptés  par  le  collaborateur,  l'équipe, 
l'organisation,  les  clients,  etc.  Il  est  également  important  que  ceux-ci  s'inscrivent  dans 
la  vision  et  la  mission  de  l'organisation  et  naturellement  au  sein  de  la  fonction.  Lors  de 
la  formulation  d'objectifs  de  développement  personnel,  leur  caractère  recevable  doit 
s'inscrire  dans  un  cadre  plus  large  que  celui  de  la  fonction  actuelle. 

•  Réaliste:  Lors  de  la  détermination  des  objectifs,  il  est  utile  de  s'accorder  un  temps  de 
réflexion  au  sujet  de  la  faisabilité  et  du  réalisme  des  objectifs.  Si  les  objectifs  sont  trop 
ambitieux,  il  peut  être  impossible  de  les  atteindre,  ce  qui  est  inévitablement 
démotivant  pour  le  collaborateur.  C'est  pourquoi  il  est  important  de  prendre  en 
considération  les  facteurs  critiques  de  succès. 

•  Déterminé  dans  le  Temps:  Il  est  convenu  d'une  échéance  à  laquelle  l'objectif  doit  être 
atteint.  Une  ligne  du  temps  peut  éventuellement  être  tracée  sur  laquelle  sont  placés  des 
objectifs  intermédiaires. 
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8. 6. 2. 3. 2  Problématique 

La  problématique  et/ou  les  besoins  est  le  motif  pour  lequel  on  élabore  le  projet. 


La  problématique  dans  notre  projet  de  rénovation  est  la  suivante:  convertir  une 
partie  du  sous-sol  en  un  bureau  de  travail  pour  satisfaire  nos  besoins  de  travailleur 
autonome. 


Cette  idée  est  générée  par  les  inconvénients  entourant  l'absence  d'une  pièce  réservée 
uniquement  au  travail  à  la  maison  (les  enfants  qui  crient  pendant  un  téléphone  d'affaires,  la 
comptabilité  faite  sur  la  table  de  cuisine,  les  enfants  qui  jouent  sur  l'ordinateur,  la  difficulté  de 
recevoir  des  clients  en  privé,  etc.). 

Si  nous  adaptons  une  approche  de  définition  du  projet  à  travers  les  problèmes  existants  il  sera 
alors  d'usage  d'utiliser  la  méthode  5P:  Pourquoi,  Pourquoi  (du  pourquoi).  Pourquoi  (du 
pourquoi  du  pourquoi),  et  ainsi  de  suite  au  moins  jusqu'à  5  fois! 

Exemple:  Fuite  d'huile  sur  presse  hydraulique: 

1.  Pourquoi?  Filtre  bouché 

2.  Pourquoi?  Huile  sale 

3.  Pourquoi?  Particules  métalliques  dans  l'huile 

4.  Pourquoi?  Bouchon  de  remplissage  absent 

5.  Pourquoi?  Bouchon  mal  positionné  et  perdu 

Si  nous  adoptons  la  démarche  Six  Sigma  (ISO  13053-1:2011)  qui  est  de  considérer  tout  projet 
interne  ou  externe  comme  une  amélioration  de  processus  pour  diminuer  les  coûts  alors  nous 
utiliserons  une  analyse  par  comparaison  voix  du  client  (VDC)/voix  du  processus  (VOP). 

Remarque:  Il  est  aussi  parfois  d'usage  de  représenter  les  problématiques  ou  les  objectifs  du 
projet  sous  la  forme  hiérarchique  d'un  organigramme  dans  l'ordre  logique  ou  de  priorité  (cela 
dépend  de  la  politique  de  l'entreprise). 

Si  nous  adaptons  une  proposition  de  la  méthode  ITIL  il  convient  de  se  poser  aussi  5  questions 
(décidément...!): 

1.  Où  en  sommes-nous  aujourd'hui? 

2.  Que  voulons-nous? 

3.  De  quoi  avons-nous  besoin? 

4.  De  quels  moyens  disposons-nous? 

5.  Qu'attendons-nous  comme  solution? 

Comme  à  l'habitude,  il  vaut  mieux  documenter  ces  questions  dans  un  document  officiel  et 
adapter  l'ensemble  aux  besoins  de  votre  organisation. 

8.6.2.3.3  Description  du  projet  (Analyse  fonctionnelle) 

Vient  alors  l'étape  de  l'élaboration  du  but  du  projet  afin  de  répondre  adéquatement  à  la 
problématique  que  nous  venons  d'identifier.  Le  but  doit  être  unique,  sans  équivoque,  très  clair 
et  précis  afin  d'obtenir  une  compréhension  homogène  du  projet  de  la  part  de  tous  les 
intervenants. 
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Pour  bien  illustrer  la  différence  entre  un  but  (project  scope)  et  les  objectifs  (product  scope), 
nous  avons  pensé  bon  les  définir  afin  d'éliminer  dès  le  début  toute  ambiguïté  dans  les 
définitions.  Le  but,  c'est  la  finalité  du  projet,  ce  que,  concrètement,  on  veut  obtenir  à  la  fin  du 
projet.  Il  n'y  a  qu'un  seul  but  (besoin  explicite)  par  projet  et  un  seul  projet  par  but. 

Le  but,  dans  notre  cas,  sera  de  créer  un  espace  de  télétravail  au  sous-sol. _ | 

Une  fois  la  problématique  et  le  but  déterminés,  il  est  essentiel  de  considérer  les  objectifs  que 
nous  voulons  atteindre.  Par  objectifs  du  projet  (besoins  implicites),  nous  entendons  ce  à  quoi 
notre  but  devrait  répondre  une  fois  notre  projet  complété,  ou  si  vous  voulez  se  sont  les 
résultats  désirés  une  fois  le  but  atteint. 


Les  objectifs  de  notre  projet  sont  : 

1 .  avoir  un  espace  privé  de  travail 

2.  qu'il  soit  multifonctionnel  (rangement,  éclairé,  privé,  etc.) 

3.  un  endroit  non  sujet  au  va-et-vient  normal  de  la  famille 

4.  un  endroit  permettant  de  recevoir  convenablement  la  clientèle 

5.  un  espace  de  bureau  pouvant  contenir  tout  l'appareillage  nécessaire  au 
télétravail 


Attention!!!  De  nombreux  clients/mandants  supposent  certains  de  leurs  besoins  (implicites) 
évidents  (par  exemple  respect  de  normes,  maintenabilité,  etc.)  et  ne  se  prennent  pas  la  peine 
de  les  mettre  par  écrit.  Une  règle  d'or  que  nous  conseillons  est  que  rien  ne  doit  être  implicite 
et  tout  doit  être  écrit.  Ce  qui  n'est  pas  écrit  ne  fait  pas  partie  du  projet! 

Une  fois  le  but  et  les  objectifs  définis,  nous  sommes  donc  rendus  à  l'élaboration  des 
contraintes  que  nous  devons  considérer  dans  la  phase  d'identification  du  projet.  Par 
contraintes,  nous  entendons  les  obstacles  majeurs  que  nous  identifions  à  ce  stade-ci  (ou 
d'autres  que  nous  devons  chercher  à  identifier),  et  qui  peuvent  faire  achopper  le  projet  dans 
son  ensemble: 


Les  contraintes  pour  notre  projet  sont: 

1 .  le  coût  de  rénovation  de  ce  local  ne  doit  pas  dépasser  5  000  $ 

2.  le  local  doit  respecter  l'aménagement  intérieur  déjà  existant 

3.  les  travaux  devront  s'effectuer  sur  une  période  n'excédant  pas  6  semaines 


L’objectif  du  projet  consiste  donc  à  atteindre  les  résultats  finaux  convenus,  autrement  dit  à 
fournir  les  livrables  dans  les  délais  convenus,  en  respectant  le  budget  et  en  assumant  des 
risques  acceptables. 

Remarques:  On  peut  compléter  ces  derniers  points  par  un  sommaire  "d’analyse  fonctionnelle" 
qui  comprend  uniquement  les  fonctions  principales  (FP)  et  contraintes  principales  (CP).  La 
norme  XF50-151  de  l'AFNOR  propose  par  exemple  un  plan  type  de  cahier  des  charges  orienté 
fonctionnel,  c'est-à-dire  indépendant  de  la  méthode  utilisée,  ou  l'IEEE830  pour  le 
développement  logiciel. 

Personnellement,  lors  de  la  clôture  ou  lors  de  la  description  de  projet,  je  m'inspire 
fréquemment  du  standard  ISO  9126:2004  qui  bien  qu'adressée  au  domaine  du  logiciel  peut 
s'appliquer  à  mon  avis  à  beaucoup  d'autres.  Cette  norme  précise  pour  le  produit  fini  certaines 
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caractéristiques  précises  et  très  pertinentes  (mais  qui  peuvent  aussi  donc  être  utilisées  pour 
vérifier  que  la  description  du  projet  est  suffisamment  complète)  comme: 


•  l'Adaptabilité  mesure  l'aptitude  du  projet  à  faciliter  l'adjonction  de  nouvelles 
fonctionnalités  ou  la  modification  de  fonctionnalités  existantes 

•  la  Capacité  fonctionnelle  (Convenance,  Précision,  Interopérabilité,  Conformisme, 
Sécurité) 

•  la  Fiabilité  (Maturité,  Rétablissabilité,  Tolérance  aux  pannes) 

•  l'Ergonomie  qui  mesure  la  facilité  d'utilisation  pour  l'utilisateur  final 
(Apprentissabilité,  Compréhensibilité,  Opérabilité) 

•  l'Efficacité  mesure  l'aptitude  d'un  projet  à  minimiser  la  consommation  des  ressources 
qu'il  utilise 

•  la  Maintenabilité  qui  mesure  l'aptitude  d'un  projet  à  faciliter  la  localisation  et  la 
correction  d'erreurs  résiduelles  (Stabilité,  Analysabilité,  Évolutivité,  Testabilité) 

•  la  Portabilité  qui  mesure  l'aptitude  d'un  projet  à  minimiser  les  conséquences  d'un 
changement  d'environnement  (Installabilité,  Remplaçabilité,  Adaptabilité,  Conformité) 

•  la  Confidentialité  (aptitude  être  protégé  ou  à  protéger  les  données,  individus  ou 
brevets) 

•  la  Couplabilité  mesure  l'aptitude  du  projet  à  être  intégré  dans  un  ensemble  plus  vaste 

•  la  Réutilisabilité  (ou  Modularité)  qui  mesure  l'aptitude  des  livrables  du  projet  à  une 
réutilisation  de  tout  ou  partie  de  ses  composants  dans  le  cadre  d'un  autre  projet 

•  la  Robustesse  mesure  l'aptitude  du  livrable  à  conserver  un  comportement  conforme 
aux  besoins  dans  le  cas  d'événements  imprévus 

•  la  Testabilité  mesure  l'aptitude  d'un  livrable  à  faciliter  la  vérification  de  son 
comportement  par  rapport  à  des  critères  de  test  et  de  recette 


Ce  qui  peut  être  résumé  par  l'excellente  figure  suivante: 

Inte  ro  pé  rab  Mité 
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Dans  mon  entreprise,  nous  utilisons  notre  manuel  ISO  9001:2008  par  exemple  les  critères 
suivants  pour  le  développement  de  nouveaux  produits  (critères  plus  complets  que  la  norme 
ISO): 

1.  Rationalisation  (s'assurer  que  les  produits  déjà  en  possession  ne  peuvent  pas  déjà 
faire  la  même  chose  ou  qu'un  interne  a  déjà  développé  une  solution). 

2.  Marque  (garantie  de  pérennité  de  l'entreprise  proposant  le  produit,  son  suivi  et  sa 
documentation,  réputation/ancienneté,  éthique) 

3.  Accessibilité  (complication  pour  se  procurer  le  produit,  l'amener  à  un  support, 
contacter  un  support,  horaires,  site  internet,  formulaires  de  contacts) 

4.  Qualité  (qualité  a  priori,  réputation/commentaires  sur  Internet,  échantillonnage,  etc.) 

5.  Exactitude  (fonctionnement  à  la  première  utilisation,  calculs  testés,  service/produit 
certifié  conforme,  preuve  de  conformité) 

6.  Communication  (politesse,  respect,  considération,  amabilité  de  tous  les  intervenants 
dans  l'écosystème  du  produit) 

7.  Temps  (temps  d'attente  pour  la  mise  à  disposition,  la  modification,  le  support,  la 
promptitude,  etc.) 

8.  Prix  (justification  détaillée  du  prix,  benchmarking) 

9.  Cohérence  (produit  est  toujours  fourni  avec  la  même  régularité  de  façon  rationnelle  et 
homogène) 

10.  Performance  (contrôlé  avec  un  test  de  Wilcoxon  pour  données  appariées) 

11.  Utilisabilité  (facilité  d'utilisation,  ergonomie/esthétique,  temps  de  formation) 

12.  Adaptabilité/Portabilité  (mesure  l'aptitude  du  projet  à  faciliter  l'adjonction  de 
nouvelles  fonctionnalités  ou  la  modification  de  fonctionnalités  existantes) 

13.  Accessoires  (disponibilité  des  compléments  au  fonctionnement  de  base  du  produit  et 
leur  pérennité) 

14.  Fiabilité  (MTTF/MUT,  disponibilité  du  support  technique,  taux  de  bugs/défauts,  etc.) 

15.  Maintenabilité  (moyens  de  maintenance  préventive,  qualité  du  service  après  vente, 
réactivité  du  support,  etc.) 

16.  Conformité  (respect  des  normes/standards,  respect  de  la  législation,  description, 
contraintes) 

17.  Durabilité  (pérennité,  développement  et  suivi  garanti  à  long  terme,  obsolescence 
programmée,  etc.) 

•  Confidentialité  (aptitude  être  protégé  ou  à  protéger  les  données,  individus  ou  brevets) 

•  Réutilisabilité  (mesure  l'aptitude  des  livrables  du  projet  à  une  réutilisation  de  tout  ou 
partie  de  ses  composants  dans  le  cadre  d'un  autre  projet) 

•  Robustesse  (mesure  de  l'aptitude  du  livrable  à  conserver  un  comportement  conforme 
aux  besoins  dans  le  cas  d'événements  imprévus) 

•  Testabilité  (mesure  l'aptitude  d'un  livrable  à  faciliter  la  vérification  de  son 
comportement  par  rapport  à  des  critères  de  test  et  de  recette) 

18.  Complétude  (est-ce  que  le  produit  satisfait  a  posteriori  les  besoins) 


8. 6.2.3. 4  Analyse  structurelle 
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L'analyse  structurelle  est  une  méthode  de  structuration  d'une  réflexion  collective.  Le  projet 
retenu  peut  être  considéré  comme  un  système  et  peut  être  défini  comme  un  ensemble 
d'éléments  en  interaction  et  de  faire  ressortir  éventuellement  certains  aspects  inattendus  ou 
contre-intuitifs  du  comportement  d'un  système  (exigences  du  système,  architecture  du 
système,  plan  d'intégration  du  système,  etc.). 

Remarque:  L'analyse  structurelle  est  souvent  abrégée  "QFD"  pour  Quality  Function 
Deployment  par  les  anglophones.  Les  japonais  parlent  eux  de  "VOC"  pour  Voice  Of 
Customer. 

L'objectif  est  dons  se  poser  les  bonnes  questions  et  de  mettre  en  évidence  des  variables 
(critères)  influents  et  dépendants. 

Deux  techniques  courantes  pour  procéder  à  cette  analyse  sont: 

-  Les  tableaux  à  double  entrée  où  l'on  indiquera  juste  une  dépendance  ou  une  dépendance 
pondérée  (il  n'y  a  pas  de  lecture  unique  -  comprendre:  scientifique  -  d'un  tel  tableau,  c'est  au 
groupe  de  travail  de  se  forger  sa  propre  interprétation): 
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Il  est  cependant  possible  d'utiliser  les  techniques  des  chaînes  de  Markov  (voir  mon  livre  de 
Mathématiques  appliquées)  pour  identifier  les  variables  ayant  le  poids  le  plus  fort  (algorithme 
de  Markov  similaire  à  celui  du  Page  Range  de  Google). 

-  Les  House  of  Quality  de  Six  Sigma  qui  bien  qu'initialement  dédiées  à  la  qualité  peuvent 
aussi  très  bien  être  adaptées  à  l'analyse  structurelle  (le  PMI  recommande  cet  outil  aux 
responsables  de  projets  pour  sélectionner  les  potentiels  meilleurs  mandataires): 
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Figure  20  Maison  de  la  qualité  Six  Sigma  (Matric  de  Pugh26) 

Il  s'agit  bien  évidemment  d'une  version  complexifiée  des  matrices  de  relation  (abusivement 
certains  utilisent  le  terme  de  "corrélation"  normalement  réservé  aux  statistiques...)  comme 
celle  ci-dessous: 


26  Stuart  Pugh 
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Corrélation 

Aucune  : 

Faible  :  Q 

Moyenne  ;  ® 

Forte  :  ^ 

Poids 

Teneur  en  sucre 

Caféine 

Température  Initiale 

Colorant  XC  27 

Ingrédient  A 

Ingrédient  b 

Caractéristique 
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Figure  21  Matrice  de  relation  (source:  ISBN  2708130226) 

où  la  première  colonne  (Goût,  Chaleur,  Tenseur  en  sucre,  Couleur)  donne  les  attentes  des 
clients  classées  par  ordre  décroissant  d'importance  avec  dans  la  deuxième  colonne  les  poids 
respectifs  (9  clients  ont  dit  que  le  coût  était  le  plus  important,  7  ont  dit  que  c'était  la  chaleur, 
etc.). 

La  ligne  située  au-dessus  des  caractéristiques  nous  trouvons  la  tendance  du  but  recherché  (ou 
déjà  atteint). 

Au  croisement,  nous  avons  les  corrélations  empiriques  (Aucune=0,  Faible=2,  Moyenne=3, 
Forte=5).  Ainsi  dans  le  cas  de  la  teneur  en  sucre,  nous  avons: 


9-5  +  6-5  =  75 


etc.  Ainsi,  cette  matrice  nous  montre  que  c'est  le  teneur  en  sucre  qui  a  posteriori  est  la  plus 
importante  pour  les  clients.  Il  faut  donc  agir  sur  elle  avec  précautions.  Concernant 
l'ingrédient  A  il  présent  peu  d'importance,  donc  nous  pourrions  jouer  avec  sans  que  cela 
représente  a  priori  un  trop  gros  risque  vis  à  vis  des  clients. 

Nous  pouvons  également  compléter  la  mais  de  la  qualité  avec  un  comparaison  de  la 
concurrence.  Ce  qui  peut  donner: 
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Corrélation  entre 
caractéristiques 
Positive  faible  :  Q 
Positive  forte  :  © 
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Figure  22  Maison  de  la  qualité  (source:  ISBN  2708130226) 

8. 6.2.3. 5  Identification  et  analyse  des  options 

Dans  cette  présente  section,  nous  devons  définir  les  différentes  options  ou  alternatives 
potentielles  que  nous  prendrons  en  considération  dans  l'élaboration  de  notre  projet.  Quels  sont 
les  divers  scénarios  que  nous  pouvons  considérer  et  qui  nous  permettront  d’atteindre  le  but 
fixé? 


Les  options,  dans  notre  cas,  sont: 

1 .  tout  faire  le  projet  soi-même 

2.  faire  exécuter  les  travaux  par  un  entrepreneur  général 

3.  être  soi-même  l'entrepreneur  et  engager  les  différents  corps  de  métier 


Après  avoir  étudié  les  avantages  et  les  désavantages  de  chaque  option,  nous  sommes  en 
mesure  de  choisir  la  meilleure,  celle  répondant  le  plus  adéquatement  à  notre  but  et  à  nos 
objectifs. 


Pour  notre  exemple,  nous  avons  choisi  l'option  3,  c’est-à-dire: 

0  effectuer  soi-même  les  tâches  d'un  entrepreneur  (coordination, 
administration,  budget  et  contrôle  de  qualité)  et  engager  les  différents  corps 
de  métier. 
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L'évaluation  du  projet  englobe  l’analyse  de  la  proposition  de  projet  au  moyen  de  différentes 
méthodes  (benchmarking27,  tableau  de  bord  prospectif,  priorisation,  etc.)  et  la  décision 
d'investir  ou  non  dans  le  projet  ou  une  de  ses  options  et  de  lui  accorder  ou  non  la  priorité  sur 
d'autres  projets  ou  d'autres  secteurs  de  l'entreprise. 

8. 6.2.3. 6  Estimation  des  intrants  et  extrants 

Il  faut  maintenant  définir  les  biens  livrables,  communément  appelés  extrants  ( output )  de  notre 
projet.  Les  extrants  du  projet  représentent  le  résultat  espéré  à  la  fin  de  celui-ci,  c’est-à-dire  «à 
quoi  ressemblera  le  produit  fini?». 


Dans  notre  exemple,  les  extrants  sont: 

1.  conception  (concevoir  le  plan) 

2.  ménage  (nettoyer  le  sous-sol  pour  recevoir  ce  bureau) 

3.  achats  (acheter  le  matériel  de  construction) 

4.  construction  (coordonner  l’activité  de  construction) 

5.  aménagement  intérieur  (peinturer  et  poser  les  rideaux) 


Pour  les  extrants  il  peut  être  utile. . .  d’analyser  les  brevets,  règlements,  avoir  des  entretiens 
avec  des  utilisateurs  ou  des  experts,  étudier  les  modes  d’emploi  des  produits  similaires  ou  en 
contact  avec  le  système  à  concevoir. 

Les  intrants  constituent  les  ressources  humaines,  matérielles  et  financières  nécessaires  à 
l’élaboration  des  extrants  (biens  livrables). 


Dans  notre  exemple,  les  intrants  sont: 

1 .  en  ressources  humaines:  un  menuisier,  un  plombier,  un  électricien,  un 
tireur  de  joints,  un  peintre,  un  décorateur,  un  poseur  de  tapis,  un  technicien 
d’une  compagnie  de  téléphone. 

2.  en  ressources  matérielles:  selon  les  besoins  de  chaque  corps  de  métier 
(bois,  fils  électriques,  peinture,  tapis,  etc.). 

3.  en  ressources  financières:  disponibilité  de  5000  $. 


Un  petit  schéma  pouvant  résumer  une  situation  plus  générale  ne  fera  pas  de  mal  si  l’on 
considère  la  réalisation  d’un  projet  comme  un  processus  de  production: 


27  Rappelons  que  le  benchmarking  permet  de  faire  du  management  sur  des  données  factuelles  et  plus  seulement 
sur  des  impressions,  des  préjugés  (ou  du  copinage).  Certaines  mauvaises  langues  disent  (et  elles  n'ont  peut-être 
pas  totalement  tort)  que  les  benchmarks  utilisés  à  tort  et  travers  (objectifs  de  vente/productivité)  sont  les  outils 
des  managers  et  conseillers  en  tous  genres  qui  ne  produisent  absolument  rien  et  contrôlent  tout... 
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Rejets 

polluants  eau , 
air,  sol ,  déchet. 


4 


Flux  sortant 

Produit  transformé, 
co-produits,.. 


Consommations 

matériaux ■  énergies,  eau , 
produits  chimiques , 
transports  sur  achats , 
infrastructures,  outillages.. 


Concernant  les  ressources  financières  il  est  conseillé  de  toujours  faire  au  moins  trois  scénarios 
(optimiste,  attendu,  pessimiste)  ou  de  faire  appel  à  des  outils  de  modélisation  de  Monte-Carlo 
ou  Bootstrapping  dans  le  meilleur  des  cas. 

Un  pessimiste  est  un  optimiste  qui  a  de  l'expérience 

Un  pessimiste  voit  des  difficultés  dans  chaque  opportunité,  une  optimiste  une  opportunité 

dans  chaque  difficulté 
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8. 6.2.3. 7  Evaluation  des  risques/menaces 


Espérer  le  meilleur  mais  toujours  envisager  le  pire... 

Le  risque  est  l'effet  naturel  de  l'incertitude  de  l'environnement  sur  l'atteinte  des  objectifs. 
Prévoir  le  pire  permet  souvent  de  l'éviter...  d'ailleurs,  les  meilleurs  guerriers  ont,  de  tout 
temps,  été  ceux  qui  faisaient  tout  pour  vaincre  et  survivre,  mais  qui  étaient  prêts  à  tomber  au 
combat  car  fondamentalement  mesurer  tout  risque  est  une  illusion  (car  la  somme  de  l'Univers 
de  tous  les  risques  fait  que  le  risque  est  de  100%...). 


Wr 


"Ce  que  l'homme  ne  veut  pas 
apprendre  par  la  sagesse,  il 
l'apprendra  par  la  souffrance" 


Évidemment,  aucun  projet  quel  qu'il  soit  ne  se  planifie  sans  comporter  de  manière  inhérente 
des  risques  directs  ou  indirects  avec  ou  sans  effet  domino.  Tous  les  gérants  de  projets  (n'ayant 
pas  des  marges  énormes  dans  la  vente  de  leurs  produits. . .)  vous  diront  l'importance  de  bien 
identifier  les  risques  dès  la  phase  d'identification  (avec  si  possible  toujours  une  ou  plusieurs 
analyses  d'autres  observateurs)  afin  de  déterminer  leur  impact  sur  le  projet  ainsi  que  les  plans 
de  contingence. 

Ainsi,  selon  la  BABOK  (Business  Analysis  Body  of  Knowledge)  outre  identifier  les  risques, 
le  plus  important  est  surtout  de  se  préparer/s'entraîner  à  gérer  des  situations  peu  probables 
avec  des  actions  prédéfinies  par  le  type  de  risque  identifié  avec  des  intervenants  que  l'on  ne 
connaît  pas  forcément  et  des  outils  que  l'on  ne  possède  pas  nécessairement  dans  un  laps  de 
temps  très  court  (entraînement  à  la  gestion  du  stress  en  situation  de  crise  comme  le  fait  la 
NASA  ou  certains  corps  de  pompiers).  Les  équipes  préparées  à  ce  genre  d'exercice  à  risques 
sont  appelées  des  "Think  Task  Force". 

Évidemment  notre  système  économique  actuel  nous  impose  (malheureusement)  de  trouver  un 
équilibre  entre  les  coûts  que  génèrent  l'identification  et  la  gestion  des  risques  par  rapport  aux 
avantages  obtenus  à  court  ou  à  long  terme  compte  tenu  des  obligations  légales,  réglementaires 
ou  autres  exigences.  Toute  décision  stratégique  à  ce  niveau  doit  être  clairement  établie  et 
formalisée  noir  sur  blanc! 

Les  contre-mesures  à  mettre  en  œuvre  ne  sont  pas  uniquement  des  solutions  techniques 
(informatiques  ou  mathématiques)  mais  également  des  mesures  de  formation  et  de 
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sensibilisation  à  l'intention  des  intervenants  (utilisateurs,  clients,  etc©,  ainsi  qu'un  ensemble 
de  règles  clairement  définies. 


Déjà  voici  quelques  risques  typiques: 


Décès/Faillite  client 

Inondations 

Tremblements  de  terre 

Décès/Faillite  fournisseur 

Affaissement  de  terrain 

Tornades/Tempêtes  (vent) 

Décès  collaborateur 

Sécheresse 

Accident  de  transports 

Accident/Maladie  client 

Indisponibilités  ressources 

Surdisponibilité  ressources 

Accident/Maladie  fournisseur 

Bugs/défaillances  informatique 

Législation/Normes 

Accident/Maladie  collaborateur 

Violation  brevets/copyright 

Conflits  d'intérêts 

Grêle 

Dépassement  délais/budgets 

Objectifs  qualité 

Incendie 

Méthodes  communication 

Formalisation  communication 

Formation  (manquante) 

Documentation  (absente) 

Check-lists  (inexistantes) 

Processus  (inexistants) 

Chartes/Directives  (absentes) 

Nomenclature  (inexistante) 

Base  de  connaissance  (inexistante) 

Traçabilité  (inexistante) 

Confidentialité  des  données 

Maîtrise  des  médias  (absente) 

Espionnage  industriel 

Contrôles  qualité  absents 

Pollution  (directe  ou  indirecte) 

Cycle  de  vie  non  modélisé 

Obsolescence  programmée 

Garanties  (absentes) 

Fluctuation  des  prix 

Fluctuation  de  la  demande 

Innovation  concurrence 

Clarté  des  objectifs 

Termes  contractuels 

Absence  audit  fournisseurs/internes 

Mental  des  ressources 

Concurrence 

Opinion  publique/politique 

Oubli  des  standards  et  lois 

Évolution  technologique 

Risque  produit/production 

Risques  humaines/social 

Irrégularité  des  contrats 

Erreurs  d'interprétation 

Pertes  humaines 

Absence  d'audit  des  risques 

Fonds  propres  manquants 

Absence  de  back-up 

Absence  de  scénarios 

Pas  d'assurances  ou  réassurances 

Sinistres  mobilier/immobilier 

Absence  de  règles  d'hygiène 

Discrimination 

Oubli  d'appel  d'offres 

Manque  de  formation 

Inexactitude  du  reporting 

Accès  de  sécurité  trop  étendus 

Absence  contrôle  information 

Règles  fiduciaires  non  respectées 

Infraction  à  la  concurrence 

Délits  d'initiés 

Financement  indirect  non  contrôlé 

Embargos 

Abus  de  pouvoir 

Dissimulations  volontaires 

Vols/ Agressions 

Fraudes  internes  ou  externes 

Malveillance  informatique 

Erreurs  de  saisie  informatique 

Offre  publique  d'achat 

Abus  de  confiance 

Fraude  (substitution  de  produits) 

Non  suivi  des  tâches 

Conflits  employés/employeurs 

Conflits  entre  employés 

Conditions  de  travail  (santé) 

Erreurs  comptables/calculs 

Complexité  produit 

Suivi  des  erreurs  (absent) 

Erreur  de  programmation  (code) 

Mauvaise  évaluation  capacité 

Suicide 

Hacking/Piratage  Informatique 

Éruption  Solaire  majeure 

Terrorisme 

Recours  juridiques  pour  adjudications 

Absence  de  compétences/Trop  de 
compétences 

Nuisance  sonores 

Matières/Liquides  dangereux 

Grêle,  Sinkhole 

Tsunami,  Avalanches 

Tableau  15  Liste  de  risques  typiques  potentiels  (non  exhaustive) 


Les  risques  par  définition  réduisent  la  probabilité  d'atteindre  ou  de  dépasser  les  objectifs  du 
projet  et  de  respecter  les  conditions  générales  et  sont  souvent  sous-estimées  car  on  oublie 
toujours  des  risques  possibles. 

100%  des  sinistrés  ont  tenté  leur  chance... 

La  gestion  des  risques  est  différente  de  l'évaluation  et  identification  des  risques!!!  Il  s'agit  d'un 
processus  continu  qui  se  déroule  dans  toutes  les  phases  du  cycle  de  vie  du  projet  (surveillance, 
audits,  cartes  de  contrôles,  etc.)  et  nous  y  reviendrons  à  la  page  292. 
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Dans  notre  exemple  ,  les  risques  que  nous  avons  identifiés  sont: 

0  ne  pas  obtenir  un  permis  de  rénovation  de  notre  ville 
0  les  corps  de  métier  non  disponibles  aux  dates  désirées 
0  ne  pas  disposer  de  l'argenl  nécessaire  aux  rénovations 
0  les  spécifications  du  projet  étant  complexes,  on  risque  de  se  tromper 
0  autres  (le  client  est  exigeant  quant  aux  biens  livrables,  les  délais  et  les  coûts 
inattendus  durant  la  construction  sont  possibles,  etc.) 


L'évaluation  des  risques  permet  au  gérant  de  projet  d'être  proactif  et  de  prendre  les  mesures 
qui  s'imposent  pour  prévenir  ou  corriger  les  problèmes  selon  les  quatre  étapes  minimales  ci- 
dessous  (il  s'agit  d'une  partie  des  étapes  de  l'ISO  31000): 

1 .  Identification  du  risque 

2.  Analyse  du  risque 

3.  Évaluation  du  risque 

4.  Traitement  du  risque  (si  l'événement  indésiré  a  lieu) 

Le  PMBOK  propose  également  quatre  techniques  pour  gérer  les  risques: 

1.  Éviter  (Avoid):  Changer  le  projet  afin  d'éliminer  le  risque 

2.  Transférer  (Transfer):  Transférer  la  responsabilité  du  risque  a  une  tierce  partie 

3.  Atténuer  (Mitigate):  Trouver  des  moyens  de  diminuer  ou  de  prévenir  le  risque 

4.  Accept  (Accpet):  Accepter  le  risque  et  préparer  un  plan  d'action  au  cas  où 
Certaines  méthodes  proposent  le  "SPASA": 

1 .  Situation 

2.  Problème 

3.  Analyse 

4.  Actions 

Dans  le  cadre  de  la  planification  de  projets  le  BABOK  propose: 

1 .  De  mettre  le  maximum  de  tâches  possibles  en  parallèle  plutôt  qu'en  séquentiel 

2.  De  forces  l'ajout  de  délais  à  la  fin  de  des  tâches  (ie.  "tâches  tampons") 

3.  Jouer  avec  la  date  de  début/date  de  fin  des  tâches  non  critiques 

4.  Essayer  de  réduire  au  maximum  le  nombre  de  tâches  présentes  sur  le  chemin  critique 

5.  Avoir  des  ressources  de  réserves  pour  les  activités  critiques 


Ingénierie  de  Gestion  de  projets 


258/547 


Ces  démarches  peuvent  se  faire  dans  le  cadre  d'un  audit  documentaire,  d'entretiens 
individuels,  de  visites  de  sites  ou  encore  de  sondages/questionnaires. 

Parce  qu'il  est  impossible  de  prévoir  toutes  les  conséquences  de  ses  actes,  le  sage  se  limite  à 

la  stricte  contemplation 

L'erreur  la  plus  courante  dans  l'identification  des  risques  consiste  à  inclure  des  marges  pour 
les  risques  dans  les  estimés  du  projet  en  utilisant  de  vieilles  méthodes  de  travail.  Il  faut  faire 
usage  des  outils  quantitatifs  de  la  finance  de  pointe  pour  se  protéger  correctement  du  risque 
que  ce  soit  en  termes  de  communications  avec  le  mandataire  ou  en  termes  d'évaluation  du 
niveau  de  risque  (protection  à  un  niveau  de  sécurité  donné  et  communiqué  de  manière 
explicite!).  Donc  il  est  important  de  quantifier  le  risque  résiduel  non  identifié  et  de  le  gérer 
avec  une  approche  probabiliste  (et  de  comprendre  à  fond  les  outils  utilisés!). 

Il  faut  également  abolir  la  hiérarchie  lorsqu'il  y  a  des  opérations  risquées  à  effectuer.  Il  est 
fréquent  que  des  subalternes  n'osent  pas  dire  à  leur  supérieur  que  telle  décision  ou 
manipulation  est  absurde.  Ce  type  de  situation  a  déjà  entraîné  des  catastrophes  dans  le 
domaine  de  l'aviation  et  c'est  une  des  raison  pour  laquelle  la  hiérarchie  est  petit  à  petit  abolie 
dans  les  cockpits  d'avion  et  que  les  check-lists  se  sont  imposées  (et  la  même  chose  se  produit 
depuis  la  fin  du  20eme  siècle  dans  le  domaine  de  la  chirurgie  ambulatoire). 

Il  est  important  également  d'avoir  un  journal  ("risk  register")  où  chaque  collaborateur  pourra 
signaler  les  risques  identifiés  en  les  affectant  à  un  "propriétaire  du  risque"  qui  sera  la  personne 
ou  entité  ayant  la  responsabilité  du  risque  (à  tous  les  niveaux!)  et  ayant  autorité  pour  le  gérer 
ou  d'en  assumer  les  conséquences.  Ceci  permet  de  responsabiliser  les  différents  acteurs  car  le 
fait  qu'un  journal  soit  tenu  permet  d'éviter  que  certaines  personnes  fuient  leur  responsabilité 
ou  accusent  une  mauvaise  communication  ou  traçabilité. 

Par  ailleurs,  les  militaires  ont  bien  compris  que  la  punition  des  erreurs  non  documentées  à 
l'origine  n'amène  à  rien  et  qu'au  contraire  il  s'agit  alors  d'un  retour  d'expérience  qui  permet  de 
prendre  du  galon.  Donc  dans  le  domaine  du  risque,  la  lutte  contre  les  actes/décisions  absurdes 
et  donc  l'amélioration  de  la  sécurité  dans  les  activités  sensibles  impose  aussi  un  recours  aux 
sciences  humaines  (l'humilité  et  l'écoute  des  avis  des  autres  par  exemple...). 

On  ne  prend  malheureusement  souvent  conscience  du  risque 
que  lorsqu  'il  est  déjà  trop  tard. 

Effectivement,  une  gestion  des  risques  développée  inclut  la  responsabilité  complète 
clairement  définie  et  acceptée  des  risques,  des  moyens  de  leur  maîtrise  et  des  tâches  de 
traitement  des  risques  (ce  sont  les  points  de  base  d'une  charte  Qualité).  Les  personnes 
désignées  acceptent  la  pleine  responsabilité,  ont  les  compétences  nécessaires  et  disposent  de 
ressources  adaptées  leur  permettant  de  vérifier  les  moyen  de  maîtrise  du  risque,  de  surveiller 
les  risques,  d'améliorer  les  moyens  de  maîtrise  du  risque,  et  de  communiquer  efficacement  sur 
les  risques  et  leur  management  avec  les  parties  prenantes  internes  ou  externes. 

Concernant  les  décisions  du  management  qui  vont  à  l'encontre  des  normes  (typiquement 
la  norme  ISO  31000  même  si  elle  n'est  pas  génialissime...),  de  la  législation  ou  des  règles 
de  sécurité,  en  plus  de  faire  signer  aux  n+ 1  leurs  décisions,  n'oubliez  pas  d'exiger  qu'ils 
indiquent  sur  le  document  signé  la  raison  pour  laquelle  ils  vont  à  l'encontre  de  vos 
avertissements! 
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Signalons  que  le  PMBOK  recommande  un  outil  très  utile  qui  consiste  à  faire  une  RBS  (rien  à 
avoir  avec  la  "Ressource  Breakdown  Structure"),  c'est-à-dire  une  "Risk  Breakdown 
Structure",  donc  en  d'autres  termes  un  organigramme  des  risques  (qui  pourra  être  réutilisé 
dans  d'autres  projets,  ce  qui  est  très  utile!). 

Signalons  aussi  que  le  B  ABOK  propose  (et  c'est  très  juste  selon  mon  point  de  vue)  de 
maximiser  la  parallélisation  des  tâches  de  planning  de  projets  car  cela  a  pour  effet  naturel  de 
diminuer  le  nombre  de  tâches  sur  le  chemin  critique  et  introduit  naturellement  des  marges  aux 
tâches! 


FAI  LU  RE  IS  NOT  AN  OPTION 


Signalons  un  cas  de  communication  quantitative  d'analyse  des  risque  qui  devient  de  plus  en 
plus  critique  à  prendre  en  compte  dans  les  entreprises  et  surtout  les  départements  I.T.  et  qui 
est  le  S.L.A.  pour  Service  Agreement  Level  et  qui  permet  de  s'assurer  du  niveau  de  fiabilité 
d'un  serveur  ou  même  d'une  machine  pendant  une  période  de  temps  donnée.  En  général,  un 
S.L.A.  est  un  document  qui  définit  la  qualité  de  service  requise  entre  un  prestataire  et  un 
client. 

Nous  n'allons  pas  ici  rentrer  dans  les  considérations  mathématiques  des  calculs  de  S.L.A.  qui 
dépassent  largement  le  cadre  de  cette  formation  de  base  (le  lecteur  pourra  se  référer  au  livre 
Mathématiques  Appliquées  pour  les  détails)  mais  il  est  intéressant  d'avoir  vu  au  moins  une 
fois  à  quoi  cela  ressemble  quand  les  données  sont  communiquée  de  façon  très  scolaire: 
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Disponibilité  en  % 

Indisponibilité  par  année 

Indisponibilité  par  mois 

Indisponibilité  par  semaine 

90  %  ("un  neuf") 

36.5  jours 

72  heures 

16.8  heures 

95% 

18.25  jours 

36  heures 

8.4  heures 

98% 

7,30  jours 

14,4  heures 

3,36  heures 

99  %  ("deux  neuf") 

3,65  jours 

7.20  heures 

1 .68  heures 

99.5  % 

1 ,83  jours 

3,60  heures 

50.4  minutes 

99.8  % 

17.52  heures 

86.23  minutes 

20.16  minutes 

99.9  %  ("trois  neuf") 

8,76  heures 

43,2  minutes 

10,1  minutes 

99.95  % 

4,38  heures 

21.56  minutes 

5.04  minutes 

99.99  %  ("quatre  neuf") 

52.56  minutes 

4,32  minutes 

1.01  minutes 

99.999  %  ("cinq  neuf) 

5.26  minutes 

25,9  secondes 

6.05  secondes 

99.9999  %  ("six  neuF) 

31,5  secondes 

2,59  secondes 

0,605  secondes 

Figure  23  Service  Level  Agreement  (source:  Wikipédia) 

8. 6.2.3. 8  Stratégie  de  réalisation 

À  cette  étape-ci,  nous  sommes  en  mesure  de  déterminer  la  stratégie  de  réalisation  de  notre 
projet.  Par  stratégie,  nous  entendons  le  «phasing»  du  projet,  comme  les  grandes  étapes  ou 
jalons  (qu'il  faut  poser  dès  le  début  dans  la  planification  du  projet)  qui  nous  permettront 
d'atteindre  le  but  et  les  objectifs  du  projet. 


Dans  notre  exemple,  la  stratégie  de  réalisation  sera: 


Phase  I 
Phase  II 
Phase  III 
Phase  IV 
Phase  V 


Conception 

Ménage 

Achats 

Construction 

Aménagement  intérieur 


mars  19xx 
avril  19xx 
mai  19xx 
juin  19xx 

juillet  19xx 


Avec  la  stratégie  de  réalisation  se  termine  l'élaboration  de  la  méthode  d'identification  du 
projet  (MIP).  En  suivant  ce  document,  nous  avons  identifié  et  articulé  logiquement  et  d'une 
manière  analytique  notre  idée.  C'est  alors  qu'il  devient  un  excellent  outil  de  communication 
puisqu'il  explique  clairement  et  sans  équivoque  le  projet  élaboré  par  le  gérant  de  projet.  Nous 
sommes  en  mesure  maintenant  de  considérer  les  dimensions  de  l'environnement  qui 
pourraient  avoir  un  effet  sur  notre  projet. 

8. 6.2.3. 9  Dimensions  de  l'environnement 

Tous  les  projets  sont  assujettis  aux  influences  externes  et  internes  de  l'environnement.  Il  est 
donc  vital,  à  ce  stade-ci  d'en  évaluer  les  impacts. 

Nous  dénombrons  communément  six  types  d'influences:  physique,  technologique, 
socioculturel,  organisationnel,  politico-légal,  économique  et  infrastructurel. 

Si  nous  reprenons  notre  exemple  d'aménagement  d'un  espace  de  travail  à  la  maison,  la 
première  dimension  à  considérer,  l'aspect  physique  comme  l'espace  disponible,  la  dimension 
de  la  pièce,  etc.  sont  des  facteurs  à  considérer. 
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Vincent  ISOZ 


La  deuxième  dimension  est  celle  de  la  technologie.  Même  si  le  projet  est  peu  complexe,  il 
faudra  tout  de  même  considérer  l'évolution  des  outils  automatisés  de  construction  comme  des 
robots  peintres,  des  outils  techniques  de  fabrication  très  perfectionnées,  etc. 

La  troisième  variable  de  l'environnement  est  tout  l'aspect  socioculturel.  Plus  important  dans 
des  projets  outre-mer  où  l'adaptation  à  une  nouvelle  culture  et  d'autres  façons  de  faire  est 
primordial  au  succès  du  projet  ainsi  que  l'intégration  des  consultants  de  pays  étrangers. 

La  quatrième  dimension  est  organisationnelle:  il  faut  respecter  les  procédures  administratives 
déjà  en  place  dans  les  organisations. 

Le  cinquième  aspect  est  politico-légal:  quelles  lois  et  quels  règlements  pourraient  avoir  un 
impact  sur  le  projet.  Pour  l'exemple  qui  nous  concerne,  l'acquisition  d'un  permis  de  rénovation 
de  la  ville  est  obligatoire  avant  l'exécution  de  tels  travaux  ainsi  que  le  respect  du  code  de 
construction. 

La  sixième  dimension  à  considérer  traite  des  aspects  économiques  tel  que  les  taux  d'intérêt,  le 
taux  de  change,  les  impôts,  etc. 

Enfin,  la  dernière  dimension  est  l'infrastructure,  surtout  considérée  dans  des  projets 
éloignés. 

Une  fois  cette  grille  complétée,  il  devient  possible  de  bien  considérer  les  facteurs 
environnementaux  pouvant  affecter  notre  projet. 

Dans  le  domaine  de  la  gestion  de  projets,  il  est  d'usage  de  parler  d'analyse  PESTEL  (Politique, 
Economique,  Socioculturel,  Technologique,  Ecologique,  Légal)  pour  résumer  ce  que  nous 
venons  de  voir.  Voici  un  schéma  qui  en  résume  les  différents  aspects: 
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Arès  avoir  obtenu  une  bonne  compréhension  du  projet  grâce  au  MIP  et  évalué  les  dimensions 
de  l'environnement,  nous  sommes  maintenant  prêt  à  débuter  la  phase  de  planification  après 
avoir  reçu  l'aval  de  continuer  le  projet  basé  sur  l'information  retenue. 


8.6.3  Planification 


Planning  Kick-off 
meeting 


Project  Handbook  Project  Work  Plan  Stakeholder  Matrix 


Plans 


Une  fois  que  l'on  maîtrise  la  compréhension  du  projet,  nous  sommes  en  mesure  d'en  débuter  la 
planification  détaillée  sous  forme  de  "modèle  de  projet"  (appelé  en  anglais  "project  baseline" 
ou  "project  model").  Cela  consiste,  dans  les  grandes  lignes,  à  établir  les  tâches  à  effectuer,  à 
identifier  les  exécutants  et  à  déterminer  le  temps  et  le  coût  théorique  de  réalisation  (à  l'opposé 
du  "planifié  réel"). 

La  figure  ci-dessous  montre  un  modèle  particulier  de  processus  de  planification  détaillé  d'un 
projet  (hors  logique  de  l'utilisation  d'un  logiciel  sinon  quoi  pour  avoir  le  protocole  d'environ 
70  étapes  se  référer  a  mon  e-books  sur  MS  Project): 


Au  début  de  cette  phase,  nous  aurons  aussi  complété  avec  les  spécialistes  adéquats  (financiers, 
logisticiens,  ingénieurs,  économistes,  etc.)  les  différentes  études  de  faisabilités:  marché, 
temporelle,  technique,  économique  et  financière  qui  sont  le  cœur  du  projet,  comme  le  montre 
la  figure  ci-dessous: 
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Étudra  de  faisabilité 


Mai:- lié 


Tempe  teils  Teckiique 


(offre  et  (peut-on 

demande,  du  leuceutier 

produit,  sources  les  delais 
potentiels  de  fixés) 

revenus,  etc.) 


(outils 

technologiques  de 
fine  peinte  pour  la 
réalisation  du  projet) 


Economique 


(analyse  der. 
coûts/bénëfices 
pour  chaque 
alternative) 


(méthode  de 
financement  et 
rentabilité  du 
projet) 


Ce  sont  elles  qui  dicteront  la  viabilité  réelle  du  projet.  L'étude  économique  établira  le 
potentiel  de  revenu  selon  des  scénarios  pessimiste,  réaliste  et  optimiste  (le  "PERT 
Probabiliste"  disponible  selon  la  loi  Beta  dans  MS  Project).  À  la  suite  de  celle-ci,  l’étude 
technique  nous  dictera  la  marche  à  suivre  afin  de  livrer  le  produit  et/ou  le  service  désiré.  De 
plus,  cette  étude  permettra  de  bien  définir  les  coûts  directs  et  indirects28  reliés  à  la  production. 

Finalement,  l'étude  financière  s'attardera  aux  revenus  et  aux  coûts.  Selon  la  durée  du  projet, 
elle  pourra  extrapoler  les  revenus  et  les  coûts  pour  ainsi  déterminer  la  valeur  actuelle  nette 
(VAN),  le  délai  de  récupération  (date  de  ROI)  et  le  taux  de  rendement  interne  (TRI)  du 
projet29.  Ces  études,  dûment  complétées,  permettront  de  décider  de  façon  bien  éclairée  si  on 
continue  ou  si  on  abandonne  le  projet.  Cela  constitue  la  deuxième  décision  de  Go/No  Go. 

Remarque:  Ces  calculs  permettent  d'éviter  à  nombre  de  gestionnaires  une  mauvaise  vision  et 
de  plus  erronée  à  court  et  long  terme  des  investissements  économiques  et  humains. 

Dans  cette  phase,  une  fois  prise  la  décision  d'aller  de  l'avant  grâce  aux  données  obtenues  par 
les  différentes  études  de  faisabilité,  on  commence  alors  la  planification  détaillée  du  projet. 

Cette  planification  permettra  de  déterminer  les  tâches,  d'estimer  les  ressources  et,  bien 
entendu,  d'évaluer  la  durée  du  projet.  La  planification  du  projet  devrait  permettre  d'obtenir  un 
document  décrivant  l'essentiel  des  tâches  à  accomplir  pour  rencontrer  le  but  et  les  objectifs 
fixés  dans  la  phase  identification.  Il  existe  plusieurs  outils  afin  de  bien  disséquer  son  projet. 
Pour  déterminer  les  tâches,  on  verra  comment  utiliser  la  structure  de  fractionnement  du 
travail  SFT. 


Il  est  à  noter  que  c'est  précisément  à  ce  moment  que  l'utilisation  d'un  logiciel 
d'ordonnancement  comme  MS  Project  peut  prendre  toute  son  importance.  À  ce  stade  de  la 
planification,  nous  sommes  en  mesure  de  bien  saisir  toutes  les  tâches  ainsi  que  toutes  les 
ressources  nécessaires  à  leur  exécution.  C'est  pour  cette  raison  que  l'utilisation  du  logiciel 
avant  cette  étape  serait,  de  notre  avis,  prématurée. 

Cette  phase  est  complétée  par  la  gestion  des  contrats  et  des  approvisionnements  selon  des 
modèles  mathématiques  comme  le  modèle  de  Wilson  (utilisé  par  les  plus  grandes  entreprises 
au  monde)  et  la  gestion  du  risque  et  de  la  maintenance  selon  des  lois  statistique  diverses 
(Normales,  Poissoniennes,  Weibull,  Khi-deux,  etc.). 


28  Coûts  sans  relations  simples  ou  immédiates  avec  le  produit  ou  le  service 

29  Voir  le  cours  de  mathématiques  financières  de  Vincent  ISOZ  sur  le  site  www.sciences.ch  ou  l'ouvrage  de  Jean- 
Pierre  Favre  aux  éditions  Digilex 
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Enfin,  signalons  qu'à  notre  époque  ou  l'empreinte  écologique  est  un  enjeu  d'image  majeur  et 
aussi  qu'en  cas  de  défaillance  grave  il  faut  prévoir  un  plan  de  remédiation,  c'est-à-dire  un  plan 
de  retour-arrière  pour  restaurer  la  situation  initiale  lorsque  c'est  possible  ou  tout  autre  action 
de  remédiation  si  le  plan  de  retour-arrière  n'est  pas  envisageable30  (i.e.  plan  de  continuité). 

8.6.3. 1  Structure  de  fractionnement  de  travail 

Un  des  éléments  clés  de  toute  planification  d'un  projet  est  sans  aucun  doute  la  structure  de 
fractionnement  de  travail  (SFT)  associée  parfois  à  la  structure  de  fractionnement  du 
produit  (PBS)  -  dans  le  domaine  de  la  production  on  parlera  plutôt  de  Nomenclature  du 
produit.  Traduite  de  l'anglais,  Work  Breakdown  Structure  (WBS),  cette  charpente  consiste  à 
découper  le  projet  en  lots  de  tâches  d'une  façon  logique,  selon  une  démarche  descendante. 

Le  gérant  du  projet  devrait  le  décomposer  en  une  structure  comme  celle  suggérée  ci-dessous: 

1.  le  projet  en  entier  se  découpe  en  un  sous-ensemble  de  lots  (SDP:  Structure  de 
Découpage  du  Projet) 

2.  les  lots  se  décomposent  en  des  tâches  simples  ou  activités 

3.  les  tâches  simples  forment  un  bloc  de  travail  dont  un  membre  de  l'équipe  de  projet  est 
responsable 

Cette  approche  permet  de  mesurer  plus  facilement  les  tâches  en  termes  de  ressources 
(financières,  matérielles,  humaines)  et  d'effectuer  des  rapports.  Chaque  tâche  du  projet  est 
ainsi  planifiée,  coordonnée  et  contrôlée  et  peut  être  identifiée  de  manière  unique  dans  le  cadre 
d'un  processus  industriel: 

Remarque:  Pour  voir  comment  créer  une  W.B.S.  (ainsi  que  R.B.S.  et  O. B. S.31)  dans 
MS  Project,  voir  le  support  de  cours  sur  le  sujet. 

Voici  un  excellent  exemple  générique  d'association  WBS/OBS/CBS: 


30  Particulièrement  utile  dans  le  domaine  de  l'informatique. . . 

31  Pour  rappel:  Resource  Breakdwon  Structure  /  Organizational  Breakdown  Structure 
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Je  recommande  fortement  de  demander  au  client  le  niveau  de  détail  du  planning  sous  forme 
de  W.B.S.  (ou  de  Gantt/PERT)  qu'il  souhaite.  Il  n'est  effectivement  pas  utile  de  facturer  du 
temps  à  faire  un  travail  de  reporting  qui  n'intéresse  pas  le  client  (cela  ne  doit  cependant  pas 
empêcher  les  responsables  de  projet  de  faire  un  planning  détaillé  qui  n'apparaîtra  simplement 
pas  en  détail  dans  le  cahier  des  charges). 

Il  faut  savoir  que  le  PMI,  dans  la  version  4  de  sa  méthodologie,  conseille  de  refuser  d'endosser 
la  charge  de  tout  projet  dont  la  WBS  est  inexistante. 

Le  niveau  de  décomposition  du  projet  est  quelque  chose  de  personnel.  J'ai  déjà  vu  des 
multinationales  gérer  des  projets  à  500M  CHF  avec  seulement  5  phases  et  aucune  tâche  et  des 
PME  gérer  des  projets  de  15'000  CHF  avec  6  phases  et  une  cinquantaine  de  tâches  et  d'autres 
entreprises  qui  ne  faisaient  rien  du  tout  pour  des  projets  compris  entre  ÎOO'OOO  et  4M  CHF. 

8.63.2  Structure  de  fractionnement  du  produit 

Une  notion  extrêmement  importante  dans  l'industrie  est  donc  la  PBS.  Pour  comprendre 
pourquoi  il  faut  y  consacrer  quelques  minutes.  Considérons  un  produit  dont  la  nomenclature 
est  la  suivante: 


Ingénierie  de  Gestion  de  projets 


266/547 


Qui  est  donc  une  représentation  arborescente  d'une  nomenclature  de  produit. 

Ainsi,  A  se  compose  d'un  sous-ensemble  B,  de  deux  sous-ensembles  C  et  de  quatre  pièces  F... 
Nous  remarquons  aussi  que  A,  B,  C  et  D  consistent  uniquement  en  des  "pièces  montées"  et 
non  fabriquées. 

Entre  parenthèses  est  indiqué  le  nombre  d'unités  nécessaires  pour  l'élément  hiérarchique 
supérieur.  Ce  nombre  est  souvent  appelé  "coefficient  technique"  ou  "coefficient  de  montage". 

En  final,  le  montage  d'une  unité  de  A  suppose  de  disposer  de  trois  unités  de  E  et  de  seize  unité 
de  F.  Ainsi,  pour  200  produits  A  commandés  (en  supposant  que  cela  corresponde  à  un 
"cycle"),  il  faut  approvisionner  600  pièces  E  et  3'200  pièces  E.  Ce  sont  les  "besoins  bruts". 

Le  problème  de  cette  représentation,  c'est  qu'elle  ne  prend  pas  compte  des  stocks  ni  des  dates. 

Pour  répondre  au  problème  de  la  production  non  datée,  nous  allons  nous  servir  du  principe  de 
calcul  des  besoins  bruts  en  prenant  en  compte  les  décalages  temporels  induits  par  l'attente  d'un 
produit  en  un  instant  donné. 

Nous  mettons  alors  la  nomenclature  à  l'horizontale  en  lui  faisant  subir  une  rotation  de  -90°  ( 
-ni  2  radians...). 

Une  planification  au  plus  tard,  donne  alors  (oubliez  de  faire  cela  correctement  avec 
MS  Project  à  ce  jour...): 
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où  nous  avons  donc  considéré  que  le  cycle  de  montage  de  A,  C  et  D  est  de  1  semaine  pour  une 
demande  de  200  unités  de  A.  Le  cycle  de  montage  est  de  2  semaines  pour  B. 

Le  délai  d'approvisionnement  de  E  est  de  1  semaine  et  celui  de  F  de  2  semaines. 

Mais  un  planning  comme  celui-ci  une  enfant  de  15  ans  pourrait  le  faire  et  c'est  donc  très  très 
très  loin  d'être  optimal  et  encore  plus  loin  d'être  conforme  à  la  réalité  (qui  nécessite  de  prendre 
en  compte  la  capacité  des  ouvriers,  la  maintenance  et  le  réglage  des  machines,  l'efficacité 
marginal  en  fonction  du  volume,  etc.).  Cette  approche  simpliste  est  appelée  parfois  "politique 
lot-for- lot". 

Nous  remarquons  avec  cette  technique,  appelée  techniquement  MPR1  comme  nous  l'avons 
déjà  mentionné  au  début  de  cet  ouvrage,  que  le  cycle  total  de  fabrication  d'un  produit  fini  (A) 
est  égal  à  la  somme  des  plus  longs  cycles  à  chaque  niveau  de  nomenclature. 

Nous  pouvons  donc  y  faire  un  parallèle  avec  un  chemin  critique  puisque  tout  retard  sur  ce 
chemin  affecte  d'autant  la  livraison  au  client. 

Indiquons  qu'il  existe  de  nombreuses  techniques  empiriques  dans  le  domaine  dont  voici  les 
noms  afin  que  le  lecteur  intéressé  puisse  approfondir  le  sujet  par  lui-même:  JIT  (Just  In 
Time/Flux  tendu),  Kanban  (OF  en  provenance  de  l'aval),  OPT  (Optimized  Production 
Technology). 

8.6.33  Techniques  d'ordonnancement 

Nous  proposons  dans  cette  partie  du  support  une  série  d'exercices  afin  de  se  familiariser  avec 
le  logiciel  MS  Project  (ou  tout  logiciel  équivalent)  et  des  concepts  faisant  partie  de  la 
connaissance  minimum  minimorum  d'un  gestionnaire  de  projets.  Dans  un  premier  temps, 
aucun  des  exercices  de  "prise  en  main"  ne  sera  en  rapport  avec  le  précédent.  Cependant,  dès 
que  nous  entrerons  dans  le  logiciel  lui-même,  nous  tenterons  d'avoir  un  seul  et  unique  projet 
avec  lequel  nous  verrons  toutes  les  possibilités  "standards"  de  MS  Project  (jusqu'au  niveau 
"orange  belt"  environ  correspondant  aux  cours  dispensés  par  l'IIL). 

Attention  dans  MS  Project,  lors  du  travail  avec  les  tâches  de  groupe  (phases):  vous  devez 
toujours  les  créer  avant  (!!!)  d'enregistrer  ce  que  nous  appelons  des  Baselines  sinon  vos  audits 
des  coûts  ne  seront  pas  corrects  en  ce  qui  concerne  le  champ  valeur  Planification. 

Avant  de  commencer  rappelons  un  élément  trivial  que  le  PMBOK  rappelle  aussi  très  bien!  La 
planification  "logicielle"  d'un  projet  se  faire  normalement  dans  l'ordre  suivant: 
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1.  Jalonnement  (milestone  schedule) 

2.  Phasage  (summary  schedule) 

3.  Ordonnancement  (planification  détaillée) 

Ces  trois  étapes  sont  souvent  représentées  un  diagramme  de  Gantt  (graphe  connexe  valué  et 
orienté)  comme  ci-dessous  (source  des  images:  PMBOK  V4): 


Milestone  Schedule 
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Calendar 
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Period  1 
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Period  3 
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Provide  New  Fîoduct  Z  Delirverable  -  Begjun 
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Figure  24  Jalonnement 
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Summary  Schedule 
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Figure  25  Phasage 
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Data  Date 


Activity 

Identifier 


1.1.  MB 
1.1.1 

1.1.1. D 

1.1.1.  B 

1.1.1. T 

1.1.1.  Ml 

1.1.2 

1.1. 2.  D 

1.1. 2.  B 

1.1.2. T 

1.1.2.  Ml 
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1.1. MF 
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Figure  26  Planning  détaillé 


et  correspondant  au  processus  numéro  6  du  PMI/PMBOK  V4: 
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Inputs 

.1  Sccpa  bassina 
2  EiterpriH  envrantrenlBl 
IbC'üf  S 

2  Crgi-iujliic  jl  iraccss  asnb 

2  TcalsA  Tachriqucs 
.1  DgcampashiDn 

2  Hülin:  vfvfa  :lamng 

3  Tarn  :1e  les 

A  Expert  judqmBTg^ 

2  C.lputt 
.1  4ctrvrty  lirt 
2  A-itM.Tt*^  strik-xs 
J  Mikdere  Isl 


Inputs 

.1  Actrirtylist 
2  .ActrvTty  attributs* 

2  4:lrvtvrc  sccrcc  rcqururront 
.-1  Rbsùltcb  calandars 
5  Prejad  sccps  :-Jkm:-r: 

JS  Er-xrprise  emTiintrefTlal 
faden 

.7  CrgarizatiMial  process  assab 

1  Twls  A  Tu  ch  ri  que  s 
.1  Exps-rt  judqmer: 

J  Aralcqeijs  Bstimasig 
2  Parameaic  cptmatrq 
A  HlvEB-par:  Bsimab  s 
5  Réserva  sralyïis 

2  Dutpuls 

.1  ÂctivrtyduraliDnastvnBlDS 
J  Project  document  updatas 


.1  hp-.ts 
.1  Actbâty  liât 
J  Acirvrty  attributs  a 
2  Mikdere  Ici 
A  Prejnd  sccps  rj^rnsr: 

J  Drgbrizadcnal  pracess  ass«3 

2  Teds  &  Tnchriques 

.1  Precndencc  dugnammng 
rretbod  lPDM| 

J  Ctpflmkncy  delt-nn  ration 

2  4::MnplaEds  ard  legs 

A  SchBduJtPBbkMDrktBmplalBS 

2  ElI  puis 

.1  Prejad  sched'Je  relwerk 
diagrams 

3  Prejnd  document  updata* 


À  Inputs 

.1  Acbvrtylist 
2  Adrvrty  attribuas  a 
J]  Prejnd  schedulBnntrark 
dsagrams 

A  ActhitY  rnsaurcB 
rcqurnrrenb 
j  Rnscurcc  crinmlErs 
JS  Acirnty  duration  edi  ma  ta: 

.7  Prejnd  sccps 
.3  EmerprÎH  cnuiranfrenbl 
factrï 

2  Drgarizaticrul  prucess  asssta 

2  Teds  A  Tnchriques 

.1  Schedule  rnbuvcrk  andysis 
2  Crncai  palh  mnthcd 

2  Crncai  char  rrethud 
A  fiescurcc  kvriing 

5  What-Hscanario  analysis 
JS  Àpptjnnq  Inbds  ard  lagx 
.7  Schedurecnmcressian 

3  ScheduiriglDcl 

2  Outputs 

.1  Prejnd  schedule 
J  E  ch  edi  Je  baseline 
2  EchedUe  data 
A  Prejad  doc wrent  updatas 


.1  Inpufes 
.1  Àcthifyliït 
2  Acthiby  attributs  a 
J  flascurce  edentbrs 
A  Enterprise  nmiranrrental 
tadi-rs 

5  Crgari.mticnal  pac casasses 

2  Te  ri  s  &  Te  chu  que  s 
.1  Expert  j u dg ment 
2  Alternante:  s  analysis 
2  Pubished  E-sb-  :th:  data 
A  BeSem-up  estimating 
5  PrcjBd  managsmerîscrmvars 

2  Dutputs 

.11  iitririty  rescurcn  rnquaements 
2  Hnsuircebreabdcum  stmctire 
2  PrcjBd  rk  eu  ms  rct  updates 

V _ 


.1  Inputs 

.1  Prejnd  managsmert  pieu 
2  PrcjBd  schedulc 
2  Weri  performance  infcrmaôan 
A  Drganiaticrul  praccasasscts 

2  Teris  k  Technique: 

.1  Farxmarca  reiriaw: 

2  Variance  analyse 
2  Prejad  management  s rf^vars 
A  Haseurce  kveing 
5  What-H  scénario  analyse 
.7  Ad|u:inglnad:  End  laqs 
.7  Eche:Llaecrnpre:c  en 
2  EcherUing  bel 

2  Outputs 

.1  Weri  performance 
me  a  se  re  monts 

2  Crganxabenal  pac  easassets 
updates 

2  Change  requnsta 
A  PrcjBd  managementplcn 
updates 

5  Prejad  document  updates 


Figure  27  Processus  n°6  du  PMI/PMBOK  pour  la  gestion  du  temps 

Signalons  que  les  deux  jalons  qui  définissent  le  début  et  la  fin  du  projet  sont  souvent  appelées 
"danglers"  en  anglais. 

8. 6.3. 3.1  Tâche 

Un  projet  est  toujours  composé  d'un  ensemble  tâches,  lots,  ou  jalons  ordonnés  et  structurés 
selon  des  relations  (voir  mon  livre  sur  Microsoft  Project)  de  type  fin  à  début  (DF),  début  à 
début  (DD),  fin  à  fin  (FF)  ou  encore  fin  à  début  (FD). 

Les  éléments  qui  définissent  normalement  (au  minimum)  une  tâche  sont  les  suivants: 

1 .  Un  début  et  une  fin 

2.  Une  durée  (estimée  ou  non) 

3.  L'estimation  optimiste  et  pessimiste  de  la  durée  et  des  coûts  (risques) 

4.  Les  ressources  travaillant  dessus 
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5.  Les  coûts  fixes 


6.  Les  relations  avec  les  autres  tâches  environnantes 

7.  Les  contraintes  (doit  commencer,  dès  que  possible) 

8.  Les  délais  ou  retards  avec  ses  prédécesseurs 

9.  L'échéance  (deadline) 

10.  Le  type  de  pilotage  (durée  fixe,  capacité  fixe,  travail  fixe) 

Attention!!  Il  faut  différencier  au  niveau  représentatif  (la  confusion  est  souvent  grande): 

1.  Un  ensemble  de  schémas  synoptiques  hors  du  temps  représentant  un  processus 
ordonné  d'actions  physiques  que  nous  appelons  communément  un  workflow 

2.  Une  succession  d'éléments  schématiques  normalisés  par  le  BPMN  représentant  un 
processus  ordonné  d'actions  physiques  ou  non  tel  qu'une  décision,  un  choix,  la 
rédaction  d'un  document,  une  action,  etc.  que  nous  appelons  communément  un 
flowchart. 

3.  Une  succession  de  tâches  physiques  ou  administratives  ou  symboliques  successives 
ordonnées,  pondérées  et  reliées  entre  elles  définissant  un  planning  type  dans  le  temps 
que  nous  appelons  communément  un  diagramme  de  Gantt. 

4.  Une  succession  de  tâches  physiques  ou  administratives  ou  symboliques  successives 
ordonnées,  pondérées  et  reliées  entre  elles  définissant  un  planning  type  hors  du  temps 
que  nous  appelons  communément  un  diagramme  de  PERT. 

Remarque:  Un  problème  fréquent  dans  les  projets  est  de  gérer  la  transition  entre  deux  tâches. 
Effectivement,  il  y  a  parfois  des  blocages  ou  oublis  à  ces  moments-là  qui  coupent  le  bon 
déroulement  de  la  planification. 

8. 6. 3. 3. 1.1  Théorie  de  la  gestion  du  temps 

Des  consultants  et  formateurs  soft  skill  en  manque  de  références  scientifiques  et  de  bagage 
technique  en  gestion  de  projets  ont  édicté  "six  lois"  (parfois  une  variant  à  huit  étant  donné  que 
chacun  peut  y  aller  de  son  petit  ajout)  de  la  gestion  du  temps  qui  sont  souvent  communiquées 
dans  les  cours  Microsoft  Outlook  (il  faut  déjà  y  aller  oser  dire  qu'on  peut  gérer  le  temps  dans 
un  agenda  en  lieu  et  place  d'un  outil  professionnel  de  gestion  du  temps. . .). 

1 .  Loi  de  Murphy:  gardez  du  temps  pour  l'imprévu 

Edward  Murphy,  ingénieur  américain  en  aérospatiale,  a  effectué  de  nombreuses 
expériences  sur  les  effets  de  la  décélération  sur  un  humain  lors  d'un  crash.  Lors  d'une 
de  ces  expériences,  le  hasard  a  voulu  que  tous  les  capteurs  aient  été  montés  à  l'envers. 
D'où  le  constat  :  «  Une  tâche  prendra  toujours  plus  de  temps  qu'on  ne  l'imagine.  Et  ce 
qui  peut  mal  tourner  tournera  mal  ». 

Mise  en  pratique  :  N'enchainez  pas  les  rendez-vous  dans  votre  agenda,  prévoyez  un 
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battement  entre  chaque.  Pour  les  tâches  à  accomplir,  prévoyez  du  temps 
supplémentaire,  surtout  si  vous  ne  maitrisez  pas  encore  le  travail  à  réaliser. 


2.  Loi  de  Carlson:  limitez  les  interruptions 

Sune  Carlson  a  dans  les  années  50  observé  l'activité  de  managers  pour  constater  qu'ils 
étaient  interrompus  toutes  les  20  minutes  en  moyenne.  Il  a  aussi  remarqué  qu'il  faut  au 
moins  3  minutes  de  concentration  avant  de  pouvoir  reprendre  et  continuer  une  tâche. 

Mise  en  pratique  :  Désactivez  dans  Outlook  le  signal  sonore  et/ou  l'alerte  visuelle 
d'arrivée  d'un  message,  mettez  votre  téléphone  sur  répondeur  ou  instaurez  une  plage 
horaire  pendant  laquelle  vous  fermez  la  porte  de  votre  bureau.  Si  vous  travaillez  sur  un 
plateau,  indiquez  à  vos  collaborateurs  quand  vous  désirez  ne  pas  être  dérangé. 

3.  Loi  de  Pareto:  focalisez-vous  sur  l'essentiel 

Cette  loi  s'inspire  des  théories  de  l'économiste  italien  Vilfredo  Pareto  qui  a  formulé  en 
1906  le  constat  que  80  %  des  richesses  sont  détenues  par  20  %  de  la  population.  Cette 
loi  est  devenue  empirique  et  se  vérifie  dans  tous  les  domaines.  Cela  donne  dans  le 
monde  de  l'entreprise  que  20%  du  travail  effectué  produit  80%  des  résultats. 

Mise  en  pratique  :  Déléguez  les  tâches  qui  peuvent  être  réalisées  par  quelqu'un  d'autre. 
Les  premières  heures  passées  au  bureau  sont  souvent  utilisées  pour  lire  ses  emails  ou 
pour  surfer  sur  internet.  Faites  ceci  plus  tard  dans  la  journée  et  commencez 
directement  avec  ces  20%  qui  produisent  80%  de  résultats. 

4.  Loi  de  Parkinson:  fixez-vous  des  délais 

Cyril  Northcote  Parkinson  a  longuement  étudié  l'administration  britannique.  Il  en  a 
déduit  en  1958  qu'un  travail  tend  à  se  «  dilater  »  pour  occuper  tout  le  temps 
disponible.  Cela  veut  dire  que  même  si  l'on  dispose  d'un  délai  important  pour 
accomplir  une  tâche,  on  consomme  la  totalité  du  temps  imparti.  Cela  veut  dire  aussi 
que  sans  délai,  la  tâche  à  tendance  à  s'éterniser. . . 

Mise  en  pratique  :  fixez-vous  des  délais  réalistes. 

5.  Loi  d'Illich:  accordez-vous  des  pauses 

Ivan  Illich,  penseur  autrichien  décédé  en  2002,  a  énoncé  la  loi  du  rendement  au 
bureau:  «  Au-delà  d'une  certaine  durée,  on  devient  moins  productif,  voir  contre- 
productif  ».  La  concentration  optimale  dure  en  moyenne  45  minutes. 

Mise  en  pratique  :  Evitez  le  sandwich  devant  votre  écran  sur  le  temps  du  midi. 
Changez-vous  les  idées  régulièrement  en  par  exemple  prenant  un  bol  d'air  frais,  en 
prenant  une  pause  café  ou  en  papotant  avec  un  collègue. 

6.  Loi  de  Laborit:  faites  le  plus  difficile  en  premier 

Le  biologiste  Henri  Laborit  a  consacré  sa  vie  à  l'étude  du  comportement  humain.  Il 
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montré  que  l'homme  est  doté  d'un  programme  biologique  de  survie  qui  lui  fait  fuir  le 
stress  et  chercher  en  priorité  le  plaisir.  C'est  «  la  loi  du  moindre  effort  ».  Le  danger  est 
de  repousser  sans  cesse  les  tâches  ennuyeuses  et  de  les  expédier  en  dernière  minute. 

8. 6.3. 3.2  Gantt 

Il  existe  divers  niveaux  de  complexités  de  la  planification  d'un  projet.  Trivialement  au  niveau 
de  l'école  secondaire,  il  s'agit  souvent  d'un  simple  listing  et  de  liaisons  de  type  "fin  à  début" 
entre  les  tâches. 

À  un  niveau  plus  avancé  (hors  de  portée  de  MS  Project  à  ce  jour  par  exemple),  nous  avons  les 
MRP32  (Materials  Requirements  Planning)  dont  l'idée  est  d'optimiser  la  chaîne  de  production 
en  fonction  des  quantités  à  produire  et  celles  en  stock  (MRPO),  en  fonction  des  coûts  de 
fonctionnement  des  machines  et  du  changement  d'outillage  (MRP1)  et  enfin  en  fonction  des 
disponibilités  réelles  des  ressources  et  des  ordres  de  fabrication  (MRP2). 

Remarque:  Les  logiciels  MRP  sont  une  sous-famille  des  logiciels  ERP.  Il  est  peut-être 
pertinente  de  signaler  que  l'implémentation  de  solutions  informatisées  ERP  à  ce  jour  est  une 
catastrophe  dans  la  majorité  des  entreprises  (bon  ces  dix  derniers  années  2000-2010  nous 
sommes  passés  de  90%  à  54%  d'implémentations  considérées  comme  des  échecs). 

Avant  de  voir  un  exemple  d'un  Gantt  (les  MRP  n'étant  pas  traités  à  ce  jour  dans  le  présent 
ouvrage)  donnons  quelques  définitions: 

1.  Jalon  instantané:  Le  jalon  instantané  est  une  tâche  d'une  durée  nulle  d'un  projet  (ou 
suffisamment  petite  pour  être  considérée  comme  négligeable)  permettant  de  faire  le 
point  sur  celui-ci  de  n'engager  la  phase  suivante  que  si  tout  va  bien. 

2.  Jalon:  Le  jalon  est  une  tâche  qui  visuellement  sur  un  planning  a  une  durée  nulle  mais 
qui  numériquement  a  une  durée  non  négligeable.  Au  même  titre  que  la  définition 
précédente,  celui-ci  permet  de  faire  le  point  sur  le  projet  et  de  n'engager  la  phase 
suivante  que  si  tout  va  bien. 

3.  Tâche:  Une  tâche  dans  un  cas  idéalisé  de  planification. . .  un  travail  ou  un  effort  réduit 
à  son  élément  le  plus  simple.  Une  tâche  peut  comporter  plusieurs  ressources  humaines 
ou  matérielles  avec  divers  consommables  affectés  ou  suraffectés. 

4.  Tâches  répétitives:  Une  tâche  répétitive  est  un  travail  ou  un  effort  qui  a  une 
récurrence  périodique  dans  les  temps  pendant  une  durée  limitée. 

5.  Tâche  de  Hammock:  Une  tâche  de  Hammock  (Hamac)  est  une  tâche  dont  la  date  de 
début  et  la  date  de  fin  sont  définies  par  deux  tâches  non  directement  connexes.  La 
durée  de  cette  tâche  et  l'effort  associé  varie  alors  automatiquement. 

6.  Tâche  critique:  Il  s'agit  d'un  type  de  tâche  dont  le  moindre  infime  retard  se  répercute 
automatiquement  sur  la  date  de  fin  du  projet  (marge  totale  nulle). 


32  PDP  en  français  pour  Plan  De  Production  ou  Programme  Directeur  de  Production  et  dans  le  cas  présent,  ne  pas 
confondre  MRP  avec  Manufacturing  Ressource  Planning  (qui  est  le  MRP2). 
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7.  Tâche  de  groupe  (ou  tâche  récapitulative):  Une  tâche  de  groupe  est  fréquemment 
assimilé  à  l'ensemble  des  tâches  d'une  phase  d'un  projet.  En  théorie  des  graphes,  nous 
l'assimilons  à  une  forêt. 

Lorsqu'une  tâche  est  créée  et  que  le  temps  le  permet,  voici  les  éléments  minimaux  qu'il  faut 
définir: 

1 .  Un  début  et  une  fin 

2.  Une  durée  (estimée  ou  non) 

3.  L'estimation  optimiste  et  pessimiste  de  la  durée  et  des  coûts  des  ressources 

4.  L'estimation  des  coûts  fixes  et  ceux  associés  aux  risques 

5.  Les  ressources  travaillant  dessus  (humaines,  matérielles  ou  budgétées) 

6.  Les  relations  avec  les  autres  tâches  environnantes  (connexité) 

7.  Les  contraintes  (fortes,  faibles  ou  strictes) 

8.  Les  délais  avec  ses  prédécesseurs  ou  successeurs 

9.  L'échéance  (deadline) 

10.  Le  type  de  pilotage  (par  l'effort,  durée  fixe,  capacité  fixe,  travail  fixe) 

11.  L'avancement  (%Complété,  %Travail  Achevé,  %  Physique) 

12.  Priorité 

Nous  reviendrons  sur  ces  12  points  un  peu  plus  en  détails  dans  mon  livre  sur  Microsoft 
Project.  Signalons  cependant  qu'en  ce  qui  concerne  les  priorités,  des  logiciels  proposant  par 
exemple  des  valeurs  de  0  à  1000  (comme  c'est  le  cas  de  Microsoft  Project)  pour  les  définir,  ne 
permettent  en  aucun  de  régler  des  problèmes  de  surcharges  et  de  respecter  les  délais.  Pour 
cela,  il  faut  faire  usage  de  techniques  mathématiques  d'optimisation  comme  il  l'est  possible 
avec  les  solveurs  (vous  référer  aux  exercices  avec  le  solveur  en  fin  de  ce  document  -  pages 
456  et  458  -  pour  voir  un  exemple  d'optimisation  d'atelier  de  production  et  un  autre  de  gestion 
de  tâches  administratives). 

Voyons  un  exemple  simple:  Chargé  de  l'organisation  d'une  enquête  marketing,  vous  devez 
établir  la  planification  des  tâches  en  fonction  des  contraintes  suivantes: 
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TACHES 

DESCRIPTION 

TACHES 

ANTERIEURES 

DUREE 

(SEMAINES) 

A 

Contacter  un 
statisticien 

/ 

1 

B 

Constituer  un 
échantillon 

/ 

3 

C 

Rechercher  des 
instituts  de  sondage 

/ 

1 

D 

Elaborer  le 
questionnaire 

/ 

4 

E 

Sélectionner  l'institut 
de  sondage 

C 

1 

F 

Test  du  questionnaire 

D 

1 

G 

Administration  de 
l'enquête 

B,  I 

5 

H 

Mise  à  disposition 
des  enquêteurs 

E 

1 

I 

Essai  du 
questionnaire 

H,  F 

2 

J 

Saisie  des  données 

G 

1 

K 

Relance  des  non 
répondants 

J 

2 

L 

Administration  des 
relances 

K 

1 

M 

Traitement  des 
données 

A,  J,  N 

2 

N 

Saisie  des  relances 

L 

1 

0 

Résultat  de  l'enquête 

M 

1 

Etablissez  un  diagramme  de  Gantt  sur  papier  A4  couché  quadrillé  pour  chacun  des  cas 
suivants: 

-  Sachant  que  l'enquête  peut  commencer  la  semaine  n°5  au  début,  quand  sera-t-elle 
terminée  avec  un  jalonnement  au  plus  tôt  (ATO)? 

-  Sachant  que  l'enquête  doit  se  terminer  la  semaine  n°26  en  fin,  quand  doit-elle 
commencer  avec  un  jalonnement  au  plus  tard  (ATA)  -  c'est-à-dire  en  rétroplanning? 

1.  Avec  un  jalonnement  au  plus  tôt,  il  faut  insérer  les  tâches  sans  liens  d'antériorité  à  partir  de 
la  semaine  5.  Ensuite,  on  continue  en  inscrivant  les  tâches  qui  ont  leurs  tâches  antérieures 
réalisées  et  ainsi  de  suite,  de  gauche  à  droite.  Cela  nous  permet  d'obtenir  le  diagramme 
suivant: 
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Au  plus  tôt 

Semaines  na 

Tâches 

Tâches 

Durée 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

avant  : 

a 

i 

- 

b 

3 

- 

c 

1 

- 

d 

4 

- 

e 

1 

C 

f 

1 

D 

g 

5 

B 

i 

h 

i 

E 

i 

2 

H 

F 

j 

1 

G 

k 

2 

J 

1 

1 

K 

m 

2 

A 

J 

A/ 

n 

1 

i 

0 

i 

M 

L'enquête  sera  donc  terminée  à  la  fin  de  la  semaine  n°24 

Reproduisez  cet  exemple  dans  MS  Project! 

Remarque:  Il  n'y  a  pas  de  problèmes  et  difficultés  particulières  lorsque  dans  MS  Project  vous 
faites  une  planification  avec  un  jalonnement  au  plus  tôt 

2.  Avec  un  jalonnement  au  plus  tard,  il  faut  insérer  les  tâches  sans  liens  de  postériorité  à 
partir  de  la  semaine  26.  Ensuite,  on  continue  en  inscrivant  les  tâches  qui  ont  leurs  tâches 
postérieures  réalisées  et  ainsi  de  suite,  de  droite  à  gauche.  Cela  nous  permet  d'obtenir  le 
diagramme  suivant: 


Au  plus  tard 

Semaines  n° 

Tâches 

Tâches 

Durée 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

après  : 

a 

1 

m 

b 

3 

9 

c 

1 

e 

d 

4 

f 

e 

1 

h 

f 

1 

i 

g 

5 

j 

h 

1 

i 

i 

2 

9 

j 

1 

k 

m 

k 

2 

y 

1 

1 

n 

m 

2 

0 

n 

1 

m 

0 

1 

- 

L'enquête  doit  donc  commencer  au  début  de  la  semaine  n°7 
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Reproduisez  cet  exemple  dans  MS  Project  avec  votre  formateur! 

Remarque:  il  n'y  a  un  problème  majeur  avec  MS  Project  que  lorsque  vous  faites  une 
planification  avec  un  jalonnement  au  plus  tard.  Effectivement,  vous  ne  pouvez  pas  créer  des 
tâches  répétitives  avec  l'outil  y  relatif  comme  vous  le  montrera  votre  formateur. 

Nous  pouvons  par  ailleurs  constater  que  dans  tous  les  cas,  la  durée  du  projet  est  de 
19  semaines. 

Autre  exemple  (moins  simple): 

Vous  êtes  chargé  de  recevoir  des  clients  pour  un  repas  gastronomique  afin  de  signer  un 
éventuel  contrat.  Vous  savez  déjà  que  ce  souper  doit  débuter  à  21h00  et  voici  les  autres 
informations  dont  vous  disposez: 

1.  L'organisation  du  repas  (d'une  durée  estimée  de  lh30)  doit  commencer  dès  18h30. 

2.  La  réservation  des  places  au  restaurant,  ainsi  que  les  précisions  culinaires,  devront  être 
effectuées  au  plus  tard  à  19h00,  sachant  que  la  démarche  durera  approximativement 
15  minutes.  Aussi,  on  peut  anticiper  le  fait  que  cette  démarche  prendra  fin  entre  18h45 
et  19h00. 

3.  Une  fois  la  réservation  achevée,  il  faudra,  le  plus  rapidement  possible,  s'atteler  à  la 
préparation  des  contrats  que  l'on  présentera  lors  du  souper.  Une  durée  d'une  heure 
maximum  sera  consacrée  à  cette  préparation. 

4.  Tout  en  élaborant  les  contrats,  on  consacrera  10  minutes  pour  téléphoner  aux  clients 
afin  de  leur  donner  les  informations  suivantes:  l'heure  du  rendez-vous  (dès  21h00)  et 
l'adresse  du  restaurant.  Les  clients  nous  informeront  du  temps  qu'ils  estiment  pour  se 
rendre  au  restaurant  (lhOO). 

5.  Cinq  minutes  avant  la  finalisation  des  contrats,  le  directeur  nous  a  fait  savoir  qu'il 
tâchera  d'être  présent  dans  le  bureau  pour  vérifier  (prévoir  10  minutes  maximum)  leurs 
contenus.  S'il  peut  par  contre  consacrer  plus  de  temps  à  la  vérification  il  nous  fait 
savoir  qu'il  viendra  plus  tôt  mais  que  dans  tous  les  cas  il  ne  restera  pas  plus  de  5 
minutes  après  la  finalisation  des  contrats.  Cette  vérification  doit  être  terminée,  au  plus 
tard,  pour  20:45  (en  cas  de  problèmes  éventuels). 

6.  Une  fois  l'appel  aux  clients  effectué  et  les  contrats  prêts,  il  faudra  compter  15  minutes 
pour  se  rendre  en  voiture  au  restaurant  où  nous  attendrons  l'arrivée  des  clients. 

7.  Quand  les  clients  arriveront  au  restaurant,  sachant  qu'ils  n'arriveront  pas  avant  21h00 
et  que  leur  déplacement  en  voiture  a  duré  lhOO,  nous  souhaiterions  savoir  alors  à  quel 
moment  précis  les  clients  auront  quitté  leurs  bureaux? 

8.  Le  repas  doit  impérativement  se  terminer  à  23h00. 

Établissez  un  diagramme  de  Gantt  sur  papier  avec  les  liaisons,  les  tâches,  les  jalons  et  les 
contraintes  ad  hoc  et  choisissez  une  échelle  des  temps  adaptée  à  l'exercice. 

Résultat  (dans  MS  Project): 
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O 

Task  Name 

Duration 

Start 

Finish 

Total  Slack 

Free  Slack 

Predecessors 

Constraint  Type 

Constraint  Date 

Début 

0  days 

19.06.06  18:30 

19.06.06  18:30 

0.03  days 

0  days 

As  Soon  As  Possible 

NA 

H 

Téléphoner  au  restaurant 

15  mins 

19.06.06  18:30 

19.06.06  18:45 

1 5  mins 

0  mins 

1 

Finish  No  Later  Than 

19.06.06  19:00 

Préparation  contrats 

60  mins 

19.06.06  18:45 

19.06.06  19:45 

55  mins 

0  mins 

2 

As  Soon  As  Possible 

NA 

m 

Appel  clients 

10  mins 

19.06.06  18:45 

19.06.06  18:55 

65  mins 

65  mins 

3SS 

Finish  No  Later  Than 

19.06.06  20:00 

0 

Contrôle  contenu  par  directeur 

10  mins 

19.06.06  19:40 

19.06.06  19:50 

55  mins 

55  mins 

3FS-5  mins 

Finish  No  Later  Than 

19.06.06  20:45 

Trajet  voiture 

15  mins 

19.06.06  20:45 

19.06.06  21:00 

0  mins 

0  mins 

4;  5 

As  Late  As  Possible 

NA 

s 

Heure  officielle  de  rendez-vous 

0  days 

19.06.06  21:00 

19.06.06  21:00 

0  days 

0  days 

6 

Must  Start  On 

19.06.06  21:00 

Attente  clients 

0  mins? 

19.06.06  21:00 

19.06.06  21:00 

0  mins? 

0  mins? 

7 

As  Soon  As  Possible 

NA 

m 

Arrivée  clients 

0  hrs 

19.06.06  21:00 

19.06.06  21:00 

0  hrs 

0  hrs 

8 

Start  No  Earlier  Than 

19.06.06  21:00 

Trajets  clients 

60  mins 

19.06.06  20:00 

19.06.06  21:00 

0  mins 

0  mins 

9SF;4 

As  Soon  As  Possible 

NA 

Repas 

90  mins 

19.06.06  21:00 

19.06.06  22:30 

30  mins 

30  mins 

9 

As  Soon  As  Possible 

NA 

0 

Fin 

0  days 

19.06.06  23:00 

19.06.06  23:00 

0  days 

0  days 

11 

Must  Finish  On 

19.06.06  23:00 

et  la  représentative  de  Gantt  associée: 


Mon  19  Jun,  18 

Mon  19  Jun,  19 

Mon  19  Jun,  20 

Mon  19  Jun,  21 

Mon  19  Jun,  22 

Mor 

0  15  30  45 

0  15  30  45 

0  15  30  45 

0  15  30  45 

0  15  30  45 

0 

Vous  pourrez  remarquer  dans  MS  Project  que  quand  une  tâche  à  une  durée  nulle  elle  s'affiche 
donc  automatiquement  en  tant  que  jalon  ce  qui  a  pour  effet  associé  que  la  case  à  cocher 
suivante  s'active  automatiquement: 
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8.6.3.33  Méthode  des  potentiels  métra  (CP/RCP) 


Ce  chapitre  est  probablement  un  des  plus  importants  dans  le  livre  relativement  à  la 
gestion  de  projets  et  l'utilisation  de  MS  Project.  Il  convient  donc  d’y  accorder  une 
attention  toute  particulière. 


Supposons  qu'un  projet  se  compose  des  tâches  abstraites  suivantes: 


TÂCHES 

TACHES  ANTERIEURES 

DURÉE 

A 

E 

3 

B 

K,C 

4 

C 

- 

3 

D 

E,J 

2 

E 

- 

2 

F 

G,L 

3 

G 

- 

4 

H 

A,M,R 

2 

J 

E 

2 

K 

C 

2 

L 

G 

5 

M 

C 

4 

N 

G 

3 

R 

J 

2 

Représenter  le  graphe  MPM  (Méthode  des  Potentiels  Metra)  en  se  rappelant  les  définitions 
suivantes: 

Dl.  La  Date  au  plus  tôt  correspond  à  la  plus  grande  cumulation  de  la  durée  des  tâches  du 
début  du  projet  jusqu'à  la  tâche  intéressée.  En  aucun  cas  cette  valeur  ne  peut  être  réduite 
théoriquement  une  fois  la  modélisation  terminée. 

D2.  La  Date  au  plus  tard  correspond  à  la  date  à  laquelle  une  tâche  doit  être  commencée  au 
plus  tard  pour  que  le  projet  soit  mené  à  bien  dans  les  plus  brefs  délais.  En  pratique,  pour  la 
déterminer,  nous  partons  de  la  fin  du  projet  et  nous  retranchons  à  la  Date  au  plus  tôt  de  la 
dernière  tâche  les  durées  au  niveau  des  tâches  antécédentes.  Lorsque  plusieurs  chemins 
partent  d'une  même  tâche,  il  faut  retenir  la  différence  la  plus  courte. 


Ingénierie  de  Gestion  de  projets 


280/547 


Nous  vous  demandons  également  de  déterminer: 

1 .  Les  tâches  critiques  et  ainsi  le  chemin  critique  (ou  critical  path  abrégé  CP) 

2.  La  marge  libre  (free  slack) 

3.  La  marge  totale  (total  slack) 

Mais  peut-être  quelques  petits  rappels  sont  nécessaires: 

Définitions: 

D4.  Une  tâche  critique  se  caractérise  par  une  date  de  réalisation  au  plus  tôt  égale  à  une  date  de 
réalisation  au  plus  tard  (donc  une  absence  de  marge).  Autrement  dit,  tout  retard  pris  dans  la 
réalisation  d'une  tâche  critique  entraîne  un  allongement  de  la  durée  totale  du  projet. 

D5.  Un  chemin  critique33  est  l'ensemble  des  tâches  critiques. 

Remarque:  Sans  contraintes  temporelles  assignées  aux  tâches  (!)  un  chemin  critique  doit 
toujours  aller  du  début  du  projet  jusqu'à  la  fin  du  projet. 

D6.  La  marge  libre  qui  indique  la  durée  sur  laquelle  une  tâche  peut  glisser  sans  bouger  la 
tâche  successeur. 


33  Malheureusement  dans  la  pratique  il  existe  plusieurs  définitions  (cf.  AACE  International  Recommended 
Practice  No.  49R-06) 
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La  marge  libre  se  calcule  comme  la  différence  entre  la  date  de  début  au  plus  tôt  d'une  tâche 
sommé  de  sa  durée  et  la  date  de  début  au  plus  tard  de  la  tâche  successeur. 

D7.  Le  marge  totale  qui  indique  la  durée  sur  laquelle  une  tâche  peut  glisser  sans  que  la  date 
de  fin  du  projet  en  soit  modifié  (si  la  valeur  est  négative  cela  indique  le  temps  qu'il  faut 
gagner  sur  la  tâche  pour  que  la  date  de  fin  du  projet  ne  subisse  pas  de  délais. 

La  marge  totale  se  calcule  comme  la  différence  entre  la  date  de  fin  au  plus  tôt  et  la  date  de  fin 
au  plus  tard  d'une  tâche  (respectivement,  la  différence  entre  la  date  de  début  au  plus  tôt  et  la 
date  de  début  au  plus  tard). 

Le  chemin  critique  de  l'exercice  proposé  est:  Début,  G,  L,  F.  Fin.  La  durée  totale  étant  donc 
de  12  jours. 


Exercice:  reproduisez  cet  exercice  dans  MS  Project  en  affichant  les  tâches  critiques  en  rouge 
dans  MS  Project  et  les  marges  des  tâches  non  critiques.  Le  résultat  obtenu  devra  être  le 
suivant: 


o 

Task  Name 

Duration 

Free  Slack 

Total  Slack 

5  29  Aug  '05 

05  Sep  '05 

1 2  Sep  'C 

T  F  S  S  M 

1  T  W 

T 

F  S  S 

M  T  W  T 

F  S  S 

M 1  T  | W 

1 

Début 

0  days 

0  days 

0  days 

+1 

1  ÜÉ! 

2 

A 

3  days 

2  days 

5  days 

m 

m 

m - i 

— 

3 

1 

B  1 

|  4  days 

3  days 

3  days 

À 

** 

- 

4 

C 

3  days 

0  days 

3  days 

i 

ib 

— 

— 

5 

D 

2  days 

6  days 

6  days 

j 

- 

6 

E 

2  days 

0  days 

4  days 

fi 

- 

— 

— 

7 

F 

3  days 

0  days 

0  days 

j 

Il 

8 

G 

4  days 

0  days 

0  days 

m 

g- 

i 

_ T 

r 

9 

H 

2  days 

3  days 

3  days 

j 

_ 

i= 

- 

10 

J 

2  days 

0  days 

4  days 

i 

& 

— 

11 

K 

2  days 

0  days 

3  days 

i 

ZI 

^ - j 

— 

12 

L 

5  days 

0  days 

0  days 

i 

F 

las 

— ; — 

13 

M 

4  days 

0  days 

3  days 

i 

; . 

— 

14 

N 

3  days 

5  days 

5  days 

i 

i 

= 

- 

15 

R 

2  days 

1  day 

4  days 

i 

■=! 

— 

• 

16 

Fin 

0  days 

0  days 

0  days 

Il  est  aussi  possible  de  rajouter  en  plus  des  colonnes  Start  et  Finish,  les  colonnes  suivantes  qui 
sont  importantes  en  fonction  de  si  la  planification  se  fait  en  AS  AP  ou  ALAP  (rétroplanning): 


Task  Name 

Duration 

Early  Start 

Start 

Late  Start 

Finish 

Late  Finish 

Early  Finish 

Début 

0  days 

29.08.05  08:00 

29.08.05  08:00 

29.08.05  08:00 

29.08.05  08:00 

29.08.05  08:00 

29.08.05  08:00 

A 

3  days 

31 .08.05  08:00 

31 .08.05  08:00 

08.09.05  08:00 

02.09.0517:00 

12.09.05  17:00 

02.09.0517:00 

B 

4  days 

05.09.05  08:00 

05.09.05  08:00 

08.09.05  08:00 

08.09.0517:00 

13.09.05  17:00 

08.09.0517:00 

C 

3  days 

29.08.05  08:00 

29.08.05  08:00 

02.09.05  08:00 

31 .08.0517:00 

06.09.05  17:00 

31 .08.0517:00 

D 

2  days 

02.09.05  08:00 

02.09.05  08:00 

13.09.05  08:00 

05.09.0517:00 

14.09.05  17:00 

05.09.0517:00 

E 

2  days 

29.08.05  08:00 

29.08.05  08:00 

05.09.05  08:00 

30.08.0517:00 

06.09.05  17:00 

30.08.0517:00 

F 

3  days 

09.09.05  08:00 

09.09.05  08:00 

09.09.05  08:00 

13.09.0517:00 

13.09.05  17:00 

13.09.0517:00 

G 

4  days 

29.08.05  08:00 

29.08.05  08:00 

29.08.05  08:00 

01 .09.0517:00 

01 .09.05  17:00 

01 .09.0517:00 

H 

2  days 

07.09.05  08:00 

07.09.05  08:00 

13.09.05  08:00 

08.09.0517:00 

14.09.05  17:00 

08.09.0517:00 

J 

2  days 

31 .08.05  08:00 

31 .08.05  08:00 

07.09.05  08:00 

01 .09.0517:00 

08.09.05  17:00 

01 .09.0517:00 

K 

2  days 

01 .09.05  08:00 

01 .09.05  08:00 

08.09.05  08:00 

02.09.0517:00 

07.09.05  17:00 

02.09.0517:00 

L 

5  days 

02.09.05  08:00 

02.09.05  08:00 

02.09.05  08:00 

08.09.0517:00 

08.09.05  17:00 

08.09.0517:00 

M 

4  days 

01 .09.05  08:00 

01 .09.05  08:00 

07.09.05  08:00 

06.09.0517:00 

12.09.05  17:00 

06.09.0517:00 

N 

3  days 

02.09.05  08:00 

02.09.05  08:00 

12.09.05  08:00 

06.09.0517:00 

14.09.05  17:00 

06.09.0517:00 

R 

2  days 

02.09.05  08:00 

02.09.05  08:00 

09.09.05  08:00 

05.09.0517:00 

12.09.05  17:00 

05.09.0517:00 

Fin 

0  days 

13.09.0517:00 

13.09.0517:00 

13.09.05  17:00 

13.09.0517:00 

13.09.05  17:00 

13.09.0517:00 
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En  l'occurrence  dans  cet  exemple  ce  qui  va  particulièrement  intéresser  le  coordinateur  de 
projet  sera  la  colonne  Laîe  Finish  en  comparaison  avec  la  colonne  Finish  (dont  la  différence 
donne  le  Total  Slack ). 

Remarque:  Rigoureusement,  MS  Project  n'utilise  pas  l'algorithme  des  potentiels  mais 
partiellement  l'algorithme  de  Dijkstra  (1971)  qui  résout  le  problème  du  plus  court  ou  plus  long 
chemin  pour  un  graphe  G=(S,A)  orienté  et  connexe  dont  le  poids  lié  aux  arêtes  est  positif  ou 
nul. 

On  peut  facilement  vérifier  que  MS  Project  utilise  aussi  cette  méthode  pour  calculer  le  chemin 
critique  (il  va  du  début  à  la  fin  et  ensuite  remonte  pour  mettre  les  tâches  en  criticité)  sur  un 
exemple  un  peu  plus  complexe. 


Attention  cependant!  !  ! 

Vous  pouvez  faire  des  liaisons  dans  MS  Project  entre  des  tâches  et  des  groupes  de  tâches  et 
avoir  certaines  tâches  du  groupe  non  liées  à  un  successeur  ou  prédécesseurs  mais  dès  lors 
l'analyse  de  la  connexité  du  graphe  devient  un  peu  plus  difficile  sur  de  gros  projets  et  ce 
même  si  le  calcul  du  chemin  critique  reste  correct.  Cependant  cela  peut  poser  de  gros 
problèmes  lors  de  l'export  des  données  vers  d'autres  outils  d'analyse. 

8. 6. 3. 3. 3.1  Chemin  critique  mathématique  VS  Chemin  critique  contraint 
par  date 

Lorsque  vous  mettez  des  contraintes  fortes  sur  une  tâche  dans  MS  Project,  son  chemin  devient 
critique  automatique.  Ce  qui  est  mathématiquement  incorrecte  par  rapport  à  la  définition  de  la 
criticité  du  MPM  mais  correcte  au  niveau  de  la  sensibilité  de  la  tâche  contrainte  et  de  ses 
tâches  environnantes. 

Remarque:  Microsoft  devrait  penser  à  une  option  permettant  de  différencier  le  chemin 
critique  mathématique  du  chemin  critique  contraint. 

Exemple:  mettez  la  tâche  H  avec  un  contrainte  forte  de  type  Must  Start  On  ou  Must  Finish  On 
et  observez  le  résultat: 
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Il  n'est  pas  possible  dans  MS  Project  de  différencier  le  chemin  critique  formel  du  chemin 
critique  contraint  sans  développer  ce  qui  est  bien  dommage.  C'est  la  raison  pour  laquelle  de 
nombreux  formateurs  spécialisés  proposent  d'éviter  l'utilisation  des  contraintes  si  c'est 
possible. 

Effectivement,  chaque  contrainte  dans  MS  Project  change  la  valeur  de  la  marge  totale! 

Il  en  est  de  même  pour  l'échéance  jDeadline}\ 

Il  semblerait  cependant  que  l'usage  de  MS  Project  est  conforme  au  standard  ANSI  (American 
National  Standards  Institute)  et  au  PMBOK  V3. . ..  mais  cela  resterait  à  vérifier. . . 

8. 6. 3. 3. 3. 2  Chemin  critique  multiple 

Considérons  le  projet  ci-dessous  dans  lequel  nous  avons  demandé  à  MS  Project  de  nous 
activer  l'affichage  du  chemin  critique: 
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MS  Project  s'arrête  à  partir  de  la  deuxième  (en  remontant  comme  le  veut  l'algorithme  - 
toujours  droite gauche)  car  la  troisième  à  une  marge  totale  non  nulle  à  cause  d'une  durée 
écoulée  sur  des  jours  chômés.  Il  faut  alors  demander  à  MS  Project  de  calculer  les  chemins 
critiques  multiples  ( multiple  critical  paths)  dans  les  options  de  calcul  du  logiciel 
(Tools/Options/Calculation)  afin  que  l'algorithme  aille  de  gauche  à  droite  pour  compléter  le 
trou.  Nous  avons  alors: 
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Attention!  Selon  mon  expérience  personnelle  cette  fonctionnalité  semble  "buguée"  lorsque  la 
planification  du  projet  est  configurée  en  ALAP  (menu  Project/Project  information! Project 
Finish  Date).  Effectivement,  si  en  mode  ALAP  (rétrplanification)  vous  avez  des  tâches  dans 
un  groupe  dont  la  contrainte  est  mise  en  As  soon  as  possible  alors  rien  ne  se  passe  lorsque 
l'option  Calcule  multiple  critical  path  est  activée.  Si  vous  la  désactivez  les  choses  reviennent 
alors  dans  l'ordre. 

8.6.3.3.33  Chemin  critique  contraint  par  liaison 


Considérons  maintenant  le  cas  suivant: 


o 

Nom  de  la  tâche 

Durée 

Marge 

totale 

Marge  libre 

Prédécesseurs 

Mai  06 

08  Mai  06 

M  M  J  V 

S  C 

>  L  M  M  J  V  S  D 

1 

Début 

0  jour 

0  jour 

0  jour 

[ 

V8- 

— §|f| — 
*£= 

P5 

2 

Tl 

1  jour? 

0  jour? 

0  jour? 

1 

3 

T2 

4  jours 

0  jour 

0  jour 

2DD 

4 

Fin 

0  jour 

0  jour 

0  jour 

3;  2 

’Y' 11.05 

Il  est  curieux  d'observer  que  Tl  est  une  tâche  critique  avec  une  marge  totale  de  0  jours  alors 
que  l'on  voit  très  bien  à  l'écran  à  droite  dans  le  Gantt  que  ce  n'est  pas  le  cas  et  qu'il  y  a  3  jours 
de  marge  totale.  Cependant,  Microsoft  a  considéré  (à  tort  selon  mon  humble  opinion  de 
scientifique)  que  la  relation  début  à  début  ayant  comme  tâche  maître  Tl  (effectivement  la 
relation  va  de  Tl  à  T2)  imposait  que  puisque  T2  est  mathématiquement  critique  alors  la  tâche 
maître  l'était  aussi  par  contrainte  de  liaison. 

On  peut  vérifier  cette  observation  en  inversant  la  relation: 
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3 

Nom  de  la  tâche 

Durée 

Marge 

totale 

Marge  libre 

Prédécesseurs 

Mai  06 

08  Mai  06 

M  M  J  V  S 

D  L  M  M  J  V  S 

D  1 

1 

Début 

0  jour 

3  jours 

0  jour 

05 

.05 

2 

Tl 

1  jour? 

3  jours? 

3  jours? 

1  ;3DD 

3 

T2 

4  jours 

0  jour 

0  jour 

Ht  ! 

4 

Fin 

0  jour 

0  jour 

0  jour 

3;2 

Conclusion  de  tout  cela:  il  me  paraît  clair  et  évident  que  Microsoft  devrait  penser  dans  ses 
prochaines  version  de  Project  (trop  tard  pour  la  2007  en  tout  cas)  de  permettre  à  l'utilisateur 
de  différencier  le  chemin  critique  mathématique  (MPM)  du  chemin  critique  contraint  par  date 
et  contraint  par  liaison. 

Remarque:  Nous  avons  fait  ici  trois  exemples  de  chemins  critiques  sur  des  projets  où  aucune 
ressource  n'est  active.  Il  convient  cependant  de  définir  le  RCP  ou  Resource  Critical  Path. 

Définition:  le  RCP  représente  les  tâches  critiques  sur  lequel  des  ressources  qui  y  travaillent 
sont  assignées  à  plein  temps  (ce  sont  donc  des  ressources  critiques!).  Ainsi  un  ajout  d'heures 
sur  un  travail  fait  une  des  ressources  critiques  sur  un  tâche  critique  aura  une  répercussion 
directe  sur  la  date  de  fin  du  projet. 

8.6.3.3.34  Chemin  critique  par  avancement 

Une  autre  situation  qui  peut  être  considérée  comme  bizarre  est  la  suivante: 


r '10 

22  M= 

TaskName 

Duratit  w  | 

Constraint  Type  T  | 

Total  Sis  T  | 

W  T 

F  S  S 

M  T 

Tl 

1  day 

As  Soon  As  Possible 

0  days 

T2 

1  day 

As  Soon  As  Possible 

0  days 

T3 

0.5  days 

As  Late  As  Possible 

0  days 

Mais  qui  s'explique  simplement  par  le  fait  que  pour  Microsoft  (et  c'est  à  mon  avis  justifié) 
lorsque  le  projet  commencera  et  que  le  %Achevé  de  la  tâche  T3  sera  non  nul  alors  elle  sera 
effectivement  critique.  Il  s'agit  donc  d'une  sorte  d'anticipation  du  chemin  critique. 

8.6.3.34  Méthode  de  la  chaîne  critique  (critical  chain) 

En  1997,  le  physicien  Eliyahu  Goldratt34  présente  la  gestion  de  projets  selon  la  chaîne 
critique,  une  approche  de  gestion  de  projets  vraiment  nouvelle  depuis  plus  de  trente  ans.  Son 
modèle  aborde  pour  la  première  fois  l'aspect  humain  et  le  côté  méthodologique  de  la  gestion 
de  projets.  Les  objectifs  de  cette  approche  sont  d'augmenter  l'efficacité  des  équipes  de  projets, 
de  privilégier  la  date  de  livraison  du  projet,  d'éviter  la  micro-gestion  des  tâches,  de  planifier  et 
de  réaliser  les  projets  surtout  dans  des  délais  plus  courts. 

La  gestion  de  projets  selon  la  chaîne  critique  repose  sur  les  concepts  suivants: 


34  Vous  remarquez  à  la  longue  que  les  innovations  majeures  en  gestion  de  projets  viennent  la  majorité  de 
personnes  provenant  des  sciences  pures  (mathématiques,  statistiques)  ou  dures  (physique/chimie).  Il  est  donc 
curieux  de  voir  que  depuis  la  fin  du  20eme  siècle  on  préfère  avoir  des  "soft  skill"  en  management  plutôt  que  des 
personnes  ayant  la  rigueur  scientifique. 
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1.  Le  "processus  d'estimation":  La  majorité  des  gestionnaires  de  projets  s'accordent  une 
marge  de  sécurité  dans  leurs  estimations  afin  de  pallier  l'incertitude  du  travail  à 
effectuer  L'ajout  de  ce  délai  dans  une  tâche  n'est  pas  une  erreur.  Il  est  raisonnable  de 
considérer  les  éléments  enjeu,  le  contexte  du  projet  étudié  pour  éviter  d'avoir  des 
estimations  trop  pessimistes  dans  le  cadre  du  projet. 

2.  Le  "syndrome  de  l'étudiant":  La  majorité  des  ressources  attendent  toujours  à  la 
dernière  minute  pour  débuter  le  travail  d'une  tâche  malgré  les  délais  qui  peuvent  être 
accordés  par  le  gestionnaire  de  projets.  Par  exemple,  pour  une  tâche  de  six  jours  de 
travail,  Eliyahu  Goldratt,  Ph.  D.  affirmerait  que  la  ressource  assignée  au  travail 
augmente  significativement  sa  productivité  seulement  au  cinquième  jour  pour  finir 
dans  les  délais  prévus. 

3.  La  "loi  de  Parkinson":  Le  délai  d'accomplissement  s'adapterait  toujours 
automatiquement  au  temps  alloué.  Il  est  étrange  de  constater  que  soit:  les  échéanciers 
sont  rencontrés  ou  qu'ils  sont  souvent  dépassés  par  les  ressources.  Les  avances  sont 
rarement  récupérées  dans  les  échéanciers. 

4.  L'élimination  des  "ressources  multitâches":  L'élimination  du  multitâche  permet  aussi 
de  livrer  les  projets  plus  tôt  en  se  basant  exclusivement  sur  l'affectation  des  ressources 
selon  les  priorités  du  projet. 

Voici  les  étapes  à  effectuer  pour  réaliser  la  mise  en  place  de  cette  méthode  qui  est  très  simple 

mais  qui  constitue  un  changement  de  culture  important,  sur  le  comment  on  gère  les  projets  et 

on  évalue  l'efficacité  de  l'équipe  de  projets. 

1.  Planifier  le  projet  à  partir  de  la  date  de  fin  cible  (ALAP)  et  vérifier  que  les  contraintes  sur 
les  tâches  soient  du  type  "le  plus  tard  possible"  (ce  qui  est  automatiquement  fait  avec 
MS  Project) 

2.  Effectuer  une  estimation  classique  selon  une  loi  bêta  de  la  durée  des  tâches  et  ne  conserver 
que  le  résultat  probabiliste  du  Gantt. 

3.  Résoudre  les  suraffectations  des  ressources  en  partant  de  la  fin  plutôt  que  du  début 
(logique  si  le  planning  est  en  ALAP. . .). 

4.  Identifier  la  chaîne  critique:  La  chaîne  critique  représente  la  plus  longue  série  de  tâches 
qui  considère  à  la  fois  les  dépendances  entre  les  tâches  et  surtout  les  dépendances  entre  les 
ressources  (puisque  le  moindre  goulot  d'étranglement  au  niveau  des  ressources  aura  aussi 
un  impact  sur  le  système).  Ce  concept  est  relativement  différent  de  la  définition  du  chemin 
critique  des  tâches  (CPM)  qui  correspond  à  la  plus  longue  série  de  tâches  du  point  de  vue 
seulement  des  dépendances  entre  les  tâches  pour  déterminer  la  date  de  fin  du  projet.  Pour 
trouver  la  chaîne  critique,  il  faut  répondre  à  cette  question:  Quelle  est  la  chaîne  de  tâches 
la  plus  longue  du  projet  qui  est  dépendante  des  ressources  ("ressource  goulot")  et  des 
tâches? 

5.  Ajouter  des  tampons/buffers:  Lors  du  processus  d'estimation,  les  délais  de  sécurité  ont  été 
supprimés  tandis  que  maintenant,  il  faut  insérer  des  tampons  dans  la  planification  pour 
ajouter  de  la  contingence.  Il  est  important  de  noter  que  les  efforts  supprimés  dans  les 
délais  de  sécurité  ne  correspondent  pas  nécessaires  aux  efforts  des  tampons.  De  plus,  les 
tampons  doivent  être  placés  stratégiquement  dans  le  projet  pour  protéger,  le  plus  possible, 


Ingénierie  de  Gestion  de  projets 


288/547 


la  chaîne  critique  du  projet  et  par  le  fait  même,  la  date  de  fin  cible  du  projet. 

Il  existe  trois  types  de  tampons: 

5.1.  Tampon  pour  le  projet  qui  permet  de  protéger  la  chaîne  critique  pour  l'ensemble  des 
activités  du  projet. 

5.2.  Tampons  pour  les  chemins  secondaires  du  projet  qui  permettent  de  s'assurer  que  les 
tâches  qui  ne  sont  pas  actuellement  sur  la  chaîne  critique  ne  basculent  pas  sur  la 
chaîne  critique  à  cause  de  délais. 

5.3.  Tampons  pour  les  ressources  qui  permettent  d'alerter  les  ressources  qu'ils  devront 
travailler  sur  une  activité  de  la  chaîne  critique.  Ce  temps  est  consacré  à  libérer  la 
ressource  de  toutes  activités  non  reliés  aux  projets.  Elle  est  même  identifiée 
formellement  comme  étant  une  ressource  critique  qu'il  ne  faut  pas  déranger  en  aucune 
circonstance. 

Le  suivi  du  projet  s'effectue  exactement  comme  pour  la  méthode  classique  du  chemin  critique, 
à  une  exception  près,  qui  est  que  la  date  de  fin  de  projet  ne  changera  pas  tant  que  le  tampon  de 
projet  n'aura  pas  été  complètement  absorbé  par  les  dépassements  de  délais  des  tâches.  La 
gestion  des  tampons  est  également  un  élément  clé  du  suivi  de  la  performance  d'un  projet  selon 
la  chaîne  critique.  Une  approche  très  intéressante  pour  gérer  les  tampons  consiste  à  diviser  les 
tampons  en  trois  zones  de  taille  égale.  La  première  est  la  zone  verte,  le  seconde  la  zone  jaune, 
et  la  troisième  la  zone  rouge.  Si  l'impact  sur  le  tampon  se  limite  à  la  zone  verte,  aucune  action 
n'est  nécessaire.  S'il  atteint  la  zone  jaune,  il  faut  évaluer  le  problème  et  réfléchir  à  une  action. 
S'il  atteint  la  zone  rouge,  il  faut  agir  immédiatement.  Les  plans  d'action  doivent  prévoir  des 
moyens  d'achever  plus  tôt  les  tâches  de  la  chaîne  non  terminées,  ou  des  façons  d'accélérer  des 
tâches  futures  de  la  chaîne  pour  sortir  de  la  zone  rouge. 

La  gestion  de  projets  selon  la  méthode  de  la  chaîne  critique  fournit  aux  gestionnaires  de 
projets,  à  la  direction  et  à  l'organisation,  une  approche  qui  permet  d'éviter  les  retards  fréquents 
et  les  dépassements  de  coûts  en: 

1 .  Utilisant  une  méthode  simple,  très  efficace  et  globale  pour  évaluer  la  performance  du 
projet  et  pour  achever  les  projets  plus  vite. 

2.  Donnant  des  moyens  concrets  pour  prendre  des  décisions  sur  l'affectation  des  ressources 
en  utilisant  la  gestion  des  tampons. 

3.  Répondant  aux  contraintes  imposées  par  les  ressources  et  non  seulement  par  les  tâches 
comme  la  technique  du  chemin  critique  (CPM). 

4.  Augmentant  l'efficacité  des  équipes  de  projets  afin  qu'elles  soient  plus  à  l'aise  avec 
l'incertitude  lors  du  processus  d'estimation. 

5.  Donnant  désormais  aux  gestionnaires  de  projets,  une  technique  efficace  pour  gérer  la 
contingence  du  projet  pour  éviter  de  subir  des  délais  à  répétition  des  ressources  comme 
dans  le  passé  avec  les  techniques  traditionnelles  de  gestion  de  projets. 

Selon  le  PMI,  la  méthode  de  la  chaîne  critique  est  différente,  il  s'agirait  d'estimer  une  durée  et 
de  coûts  de  façon  très  agressive  (en  termes  d'optimisme  bien  évidemment...)  et  de  mettre  des 
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tâches  (tampons/buffer)  qui  corrigent  cette  aspect  agressif  mais  seront  cachés  aux  exécutants 
du  projet  et  connu  seul  de  l'équipe  de  gestion  du  projet. 

8. 6. 3. 3. 5  Recherche  opérationnelle 

Lors  de  la  gestion  de  projets  et  la  logistique,  outre  le  fait  de  planifier,  il  est  (plus  que) 
souhaitable  de  savoir  optimiser.  Sans  aller  trop  loin  dans  le  domaine  de  la  recherche 
opérationnelle  (il  existe  des  cours  particuliers  sur  le  sujet),  nous  allons  faire  une  petite 
application  pratique  directe  de  cette  méthode  mais  seulement  en  utilisant  MS  Excel  (la 
méthode  mathématique  sort  de  loin  du  cadre  de  ce  cours). 

Nous  ne  traiterons  pas  ici  contre  des  techniques  de  force  brutes  pour  faire  de  la  "compression 
du  planning"  (schedule  comrpression)  et  qui  sont: 

1.  Le  "crashing"  qui  consiste  à  ajouter  des  ressources  supplémentaires  (donc  augmente 
les  coûts  et  aussi  les  risques...) 

2.  Le  "fast  tracking"  qui  consiste  à  paralléliser  au  maximum  les  tâches  (donc  diminue  les 
coûts  mais  augmente  les  risques...) 

3.  Le  "surfing"  qui  consiste  à  faire  glisser  la  charge  ou  les  tâches  dans  le  temps 
Voici  un  cas  typique  simpliste  de  Gantt  et  de  son  plan  de  charge  associé: 


1 

2 

3 

4 

|  5 

6 

7 

S 

L* 

10 

11 

12 

13 

A 


Quantité  de 
te  techniciens 
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Figure  28  Plan  de  charge  type  (source:  ©ANCORE  Managementlwww.ancoremanagement.eu) 

Dans  le  cas  du  scénario  ci-dessus  si  la  séquence  ne  peut  être  changée  et  les  délais  ne  peuvent 
être  étendus  et  des  ressources  ne  peuvent  être  rajoutées  alors  la  seule  solution  consiste  à 
déplacer  faire  glisser  la  charge  sur  tâche  B  ou  respectivement  la  tâche  C. 

Supposons  maintenant  qu'une  usine  fabrique  2  pièces  PI  et  P2  usinées  dans  deux  ateliers  Al 


Ingénierie  de  Gestion  de  projets 


290/547 


et  A2. 


Les  temps  d'usinage  sont  pour  PI  de  3  heures  dans  l'atelier  Al  et  de  6  heures  dans  l'atelier  A2 
et  pour  P2  de  4  heures  dans  l'atelier  Al  et  de  3  heures  dans  l'atelier  A2. 

Le  temps  de  disponibilité  hebdomadaire  de  l'atelier  Al  est  de  160  heures  et  celui  de  l'atelier 
A2  de  180  heures. 

La  marge  bénéficiaire  est  de  l'200.-  pour  une  pièce  PI  et  l'OOO.-  pour  une  pièce  P2. 

La  question  est:  Quelle  production  de  chaque  type  doit-on  fabriquer  pour  maximiser  la  marge 
hebdomadaire? 

D'abord,  il  est  possible  de  poser  le  système  d'inéquations: 

Al:  3X1  +  4X2<160 
A2 :  6-Xl  +  3-X2<180 
X 1,  X  2  >  0 


Ensuite,  la  fonction  économique: 


Z  =  1200-  XI  + 1000-  X2 

Le  tracé  des  deux  droites  dans  MS  Excel,  donne  le  polygone  des  contraintes  (c'est  que  l'on  fait 
dans  les  petites  classes  d'écoles): 


où  nous  voyons  de  suite  ou  sont  les  maximums  ainsi  que  l'optimum. 

Pour  résoudre  le  problème  dans  MS  Excel  (eh  oui!  MS  Project  n'est  pas  fait  pour 
l'optimisation. . .  ce  qui  est  logique!),  créez  un  tableau  du  type  suivant: 
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A 

B 

C 

47 

48 

Al:  3*X1+4*X2<=160 

XI  : 

49 

A2:  6*X1+3*X2<=180 

X2  : 

50 

X1,X2>=0 

Al  : 

=3*C48+4*C49 

51 

A2  : 

=6*C48+3*C49 

52 

Contrainte  Al  : 

160 

53 

Contrainte  A2  : 

180 

54 

Z=1200*X1+1000*X2 

Fonction  économique  : 

=1200*C48+1000*C49 

et  ensuite,  avec  le  solveur  MS  Excel,  créez  les  contraintes  adaptées  du  type  (attention  les 
références  de  cellules  ne  sont  pas  données  correctement  ci-dessous  afin  de  ne  pas  vous 
mâcher  tout  le  boulot!): 


Les  solutions  seront  après  l'exécution  du  solveur: 

XI  =  16  pcs.  X2  =  28  pcs. 

D'autres  exemples  de  recherche  opérationnelle  seront  donnés  par  le  formateur  en  annexe. 

8. 6.3. 3.6  Gestion  des  risques 

C'est  l'histoire  d'un  gars  qui  tombe  d'un  immeuble  de  50  étages  et  qui  à  chaque  étage  se 
répète  "Jusqu'ici  tout  va  bien...  Jusqu'ici  tout  va  bien...  Jusqu'ici  tout  va  bien..."  mais  ce  qui 
compte  ce  n’est  pas  la  chute...  c'est  l'atterrissage! 

Dans  un  projet,  les  risques  qui  en  menacent  le  succès  doivent  être  identifiés  et  traités  de 
manière  systématique.  Ainsi,  la  gestion  de  risques  doit: 

•  Identifier  les  risques  (déjà  vu  page  256) 

•  Définir  la  manière  de  les  mesurer  et  de  les  exprimer  (probabilité,  niveau  de  risque...) 

•  Analyser  les  risques  (causes,  effets) 

•  Évaluer  les  risques  ainsi  que  leurs  effets/conséquence 

•  Définir  les  critères  permettant  de  décider  s'il  est  nécessaire  de  traiter  un  risque 
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•  Décider  si  les  combinaisons  de  risques  seront  prises  en  compte  et  comment 

•  Réduire  ou  éliminer  (traiter)  les  risques 

•  Planifier  les  risques  résiduels 

•  Surveiller  les  risques  résiduels  ainsi  que  l'effet  des  mesures  prises  (suivi) 

•  Constituer  des  réserves  pour  les  risques  résiduels 

Le  PMI  considère  4  manières  de  gérer  les  risques: 

1.  On  les  évite  (en  mettant  en  place  des  outils  ou  méthodes  qui  les  éliminent) 

2.  On  les  accepte  (on  fait  alors  en  sorte  d'avoir  des  réserves  de  temps  ou  financières) 

3.  On  les  rejette  (ce  qui  équivaut  à  les  ignorer  purement  et  simplement) 

4.  On  les  détourne  (typiquement  en  sous-traitant  les  tâches  y  relatives  ou  en  contractant 
des  assurances) 

Ail  oflife  is  the  management  ofrisk,  not  its  élimination 

Walter  Wriston,  former  chairman  of  Citicorp 


Je  n'ai  pas  souhaité  aborder  ici  la  gestion  qualitative  des  risques  (classification  élémentaire  du 
type:  élevé,  moyen  et  faible)  ainsi  que  la  BIA  (business  impact  analysis)  car  pour  un  ingénieur 
ou  un  scientifique  cela  n'apporte  pas  grande  chose  (car  c'est  trivial)  de  savoir  que  les  risques  à 
identifier  ou  à  planifier  peuvent  être  de  type: 

•  Risques  de  type  communication:  information  trop  complexe  et  abondante  ou  au 
contraire  information  trop  simpliste  et  manquante,  non  prise  en  compte  de  toutes  les 
personnes  concernées  pour  la  communication,  oubli  des  personnes  ne  sachant  pas  lire 
ou  n'aimant  pas  avoir  accès  à  de  l'information  écrite,  manque  d'écoute  des  remarques 
de  l'équipe  de  projet. . . 

•  Risques  financiers  et  temporels:  Modélisation  par  scénarios  ou  par  méthode  de 
Monte-Carlo  (ou  Latin  Hypercubej/Bootstrapping  non  effectuée,  oubli  de  la  prise  en 
compte  des  éventuelles  variations  des  prix  des  devises  ou  matières  premières,  oubli  de 
se  couvrir  contre  le  risque  (VaR)  avec  des  fonds  propres  suffisants35. . . 

•  Risques  organisationnels:  Clarté  des  objectifs,  cahier  des  charges,  pas  de  bon 
d'acceptation,  organigramme  manquant,  degrés  de  délégation  non  définis,  processus  et 
documentation  y  relative  manquants,  pas  de  méthode  de  management,  pas  de 
certification  de  qualité. . . 

•  Risques  de  type  humain:  Disponibilité  des  ressources,  compétences  trop  grandes  ou 
trop  faibles,  formation  manquante,  motivation  absente,  stress  et  pressions  malsaine  à 
cause  de  la  mauvaise  organisation,  oubli  du  taux  de  rendement  synthétique,  absence  de 
valorisation,  lassitude  face  aux  tâches  qui  sont  toutes  prioritaires... 

•  Risques  commerciaux  et  marketing:  Offres  de  la  concurrence,  clients,  exagération 
des  compétences,  mensonges  aux  mandant. . . 


35  Grossièrement  nous  pouvons  dire  qu'en  s'alignant  sur  ce  que  proposent  les  accords  de  Bâle  il  faudrait  8%  de 
fonds  propres... 
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•  Risques  techniques:  Normalisation,  cohérence  des  spécifications,  documentation, 
système  de  redondances  manquants... 

•  Risques  liés  à  la  maîtrise  de  la  sous-traitance:  Difficile  de  contrôler  l'application 
exacte  des  normes  qualité  ou  des  conventions  de  travail,  coûts  lié  aux  contrôles  par 
plans  d'échantillonnages  plus  exigeant,  pas  de  documentation. . . 

•  Risques  juridiques:  Contrats  et  conditions  générales  artistiques. . .,  conditions  légales 
non  adaptées  au  pays  d'intervention,  protection  juridique  non  suffisante,  protection  des 
données,  oubli  de  réassurance,  appel  d'offre  non  effectué,  non  égalité  de  traitement  des 
mandataires  potentiels  lors  de  l'appel  d'offre,  délits  d'initiés,  pas  de  convention. . . 

•  Risques  liés  à  la  sécurité:  Employés  quittant  le  projet  sans  clause  rigoureuse  de  non- 
concurrence,  documents  et  laboratoires  pas  assez  sécurisés,  vol  de  matériel  possible, 
fuite  de  données  ou  oreille  indiscrètes,  manipulation  de  produits  chimiques  ou 
nucléaires  sensibles  sans  protocole,  travail  de  maintenance  sur  de  grosse  machines 
pouvant  broyer  des  membres  sans  protocole. . . 

Si  les  risques  ne  sont  pas  quantifiable  ni  intégrables  dans  des  modèles  mathématiques  (en 
exclusif  ou  en  cumulé)  permettant  de  se  couvrir  du  risque  dans  la  planification  d'un  projet  que 
ce  soit  en  termes  de  temps,  coûts  ou  de  qualité  (le  standard  ISO  31010  que  j'ai  déjà  mentionné 
plus  haut  présente  sommairement  aussi  quelques-uns  de  ces  outils  quantitatifs). 


Oti  Fiwi*T 

G-fii  KfKTB./PL,V$>  ON  A; 
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Donc  les  excuses  du  genre: 


•  «  C'est  pas  ma  faute  c'est  l'autre  qui  n'a  pas  assuré  » 

•  «  Nous  n'avions  pas  fait  de  simulations  (qu'elle  soit  probabilistes  ou  pas)  » 

•  «  Un  problème  inattendu  nous  a  fait  prendre  du  retard  » 

•  «  Nous  n'avions  pas  fait  de  scénarios  » 

•  «  C'est  vraiment  trop  injuste!  » 

•  «  Nous  n'avions  pas  pensé  à  le  faire  valider  par  l'équipe  » 

. . .  seront  mal  acceptées  voir  pas  acceptés  du  tout. 

Comme  je  l'ai  déjà  mentionné  au  début  de  cet  ouvrage,  je  viens  du  domaine  du  nucléaire. 
Avec  les  années,  je  remarque  qu'il  serait  assez  positif  que  des  responsables  de  projets  de 
l'industrie  et  des  services  classiques  aillent  observer  les  méthodes  de  travail  dans  les  centrales 
nucléaires.  Ils  y  apprendraient  ce  qu'est  la  vraie  rigueur  et  le  vrai  travail  d'équipe.  Ils 
pourraient  ainsi  y  observer  que: 

•  Chaque  semaine,  on  valide  une  par  une,  oralement  les  tâches  à  faire  avec  leur  durée 
estimée  en  la  présence  d'absolument  tous  les  responsable  techniques  de  la  centrale  et 
de  la  direction. 

•  Lors  de  l'élaboration  de  processus,  on  effectue  des  simulations  mentales  et  on  fait 
valider  par  toute  l'équipe  concernée  jusqu'à  un  accord  commun. 

•  On  s'assure  que  toutes  les  manipulations  (causes)  humaines  soient  contrôlables 
automatiquement  (électroniquement)  avant  l'effet  de  celles-ci  à  l'aide  de  systèmes  qui 
sont  doublés  voir  triplés  (redondance) 

•  On  s'assure  que  même  en  l'absence  des  êtres  humaines,  le  système  puisse  continuer  à 
tourner  et  à  s'autogérer  et  ce  particulièrement  en  cas  de  crise. 

•  On  se  prémunit  contre  toute  risque  (agression  extérieure)  par  des  moyens  colossaux  et 
ce  en  fonction  bien  évidemment  des  budgets  mis  à  disposition  de  la  politique 
nationale. 

•  Les  systèmes  de  sécurité  sont  quantifiés  et  ce  jusqu'à  ce  que  le  risque  atteigne  une 
probabilité  cumulée  de  l'ordre  de  0.000001%. 

•  Tout  est  rangé,  classifié,  identifiable  et  traçable  du  moindre  papier  au  moindre 
matériel  (application  à  l'extrême  de  la  méthode  5S). 

•  Des  audits  indépendants  et  haut  niveau  d'exigence  sont  quotidiennement  menés  (au 
pire  avec  une  fréquence  hebdomadaire) 

•  Des  simulations  de  crise  sont  régulièrement  effectuées  avec  les  équipes  dirigeantes  et 
les  employés  pour  entraîner  les  individus  à  avoir  des  comportements  adéquats  sous 
forme  de  réflexes. 

•  Le  cycle  de  vie  des  intrants  et  extrants  est  rigoureusement  étiquetée,  tracée  et  planifiée 

•  Il  y  a  une  institution  centralisée  et  indépendante  qui  contrôle  et  propose  régulièrement 
des  améliorations  constamment  au  niveau  international. 

•  etc. 

Enfin  de  ne  pas  oublier  une  chose....  en  tant  que  potentiel  mandataire  et  donc  responsable  de 
projets,  de  nombreuses  sociétés  de  services  ou  industrielles  peuvent  faire  appel  à  vos 
"compétences"  juste  parce  que  ils  veulent  se  débarrasser  des  risques  identifiés  chez  eux  en 
interne  pour  la  réalisation  du  projet  à  un  prix  bien  évidemment  forfaitaire....  risques  qu'ils  ne 
vous  communiqueront  pas  pour  que  justement  au  niveau  financier  cela  soit  vous  qui  assumiez 
les  éventuels  dépassements  (même  si  le  PMI  interdit  par  exemple  ce  genre  de  pratiques  de  par 
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son  contrat  éthique)...  Dès  lors,  le  PMI  recommande  lorsqu'on  est  prestataire  (mandataire) 
d'inclure  dans  le  contrat  une  provision  pour  le  risque  que  doit  payer  le  client  (mandant). 


Faites  aussi  attention  lors  de  la  signature  de  contrats  de  réalisation  de  projets  internationaux 
aux  variations  des  cours  de  change  des  monnaies  impliquées  dans  les  transactions  financières 
du  projet.  Il  vaut  mieux  que  le  contrat  ait  une  clause  de  type  Fixed  Price  Economie  Price 
Adjustment  (FDEPA)  afin  que  le  mandant  rallonge  l'argent  en  cas  de  variations  des  taux  de 
change  ou  que  vous  imposiez  vos  fournisseurs  de  vous  faire  des  prix  à  taux  fixe  pendant  une 
période  fixée  à  l'avance! 


8.6.3.3.6.1  AMDE(C) 

Q /T 

Le  domaine  de  l'AMDEC  (déjà  mentionné  plus  haut  dans  ce  e-book)  est  souvent  réduit  dans 
le  domaine  de  la  gestion  de  projets  à  l'analyse  qualitative  des  risques  et  leur  prévention 
qualitative  en  utilisant  un  indicateur  empirique  (qui  soit  dit  en  passant  est  plutôt  sympa  car 
simpliste...)  et  déterministe  appelé  la  "criticité"  (technique  semi-quantitative  à  l'opposé  de 
l'AMDEC  qui  est  une  technique  d'analyse  quantitative). 

Cet  indicateur  a  cependant  une  propriété  très  importante  à  cause  des  contraintes  de  la  vie 
réelle  (contrainte  souvent  financières. . .):  Il  permet  de  définir  des  priorités  basé  sur  la  relation 
empirique  simple  suivante: 


Criticité  =  Gravité  •  Fréquence 


Il  est  possible  évidemment  d'affiner  ce  type  d'approche  autant  que  l'on  veut.  Ainsi,  certaines 
entreprises  multiplient  le  tout  par  un  facteur  Détection  qui  correspond  à  la  probabilité  de  non 
détection  (...): 

Criticité  —  Gravité  •  Fréquence  •  Détection 

Il  convient  de  prendre  en  compte  le  facteur  criticité  dans  l'analyse  dans  la  gestion  élémentaire 
du  risque  et  de  les  communiquer  aux  décideurs  (responsables  des  risques).  Il  faut  surtout 
garder  une  trace  dans  un  journal  (dont  nous  avons  déjà  fait  mention)  de  toute  information  ou 
divergence  d'opinion  concernant  les  risques. 

Attention  cependant  à  une  chose!  Ce  n'est  pas  parce  qu'un  événement  à  une  probabilité  plus 
petite  ou  infiniment  plus  petite  qu'une  autre  qu'il  en  est  moins  important!!  Effectivement  il 
faut  bien  évidemment  pendre  en  compte  (de  façon  certes  un  peu  empirique)  la  gravité  de  la 
défaillance.  Ainsi,  une  centrale  nucléaire  à  beau  être  peut-être  l'OOO  fois  plus  sûre  qu'une 
central  thermique  en  termes  de  probabilités...  il  n'en  est  rien  en  termes  de  gravité  lorsqu'un 
défaillance  majeure  se  produit!  Effectivement  dans  le  cas  d'une  central  thermique  il  peut  y 
avoir  au  pire  500  personnes  touchées  alors  qu'avec  une  centrale  nucléaire  c'est  une  autre 
histoire... 


36  Pour  voir  la  "vraie"  AMDEC  se  référer  à  mon  livre  de  mathématiques  appliquée  au  chapitre  Génie  Industriel. 
Le  lecteur  pourra  également  trouver  plus  d'informations  dans  la  norme  CEI  60812  Techniques  d'analyse  de  la 
fiabilité  du  système  et  dans  la  norme  ISO  31010:2009  dans  l'annexe  B. 13. 


Ingénierie  de  Gestion  de  projets 


296/547 


Nous  voyons  ici  que  les  facteurs  utilisés  peuvent  ne  pas  être  très  clairs  s'ils  ne  sont  pas 
rigoureusement  définis  et  les  hypothèses  y  relatives  ne  sont  pas  explicitement  communiquées. 
Par  ailleurs  rien  n'indique  qu'il  s'agira  toujours  d'une  estimation!  C'est  un  danger  qu'il  ne  faut 
jamais  négliger  et  pas  uniquement  dans  le  domaine  de  l'AMDE(C)  semi-quantitative. 

Fondamentalement  l'AMDE(C)  propose  pour  atténuer  les  risques  de: 

•  Mettre  en  place  des  systèmes  de  redondance 

•  Répartir  les  machines/serveurs  (ne  pas  mettre  tous  les  œufs  dans  le  même  panier) 

•  Sauvegarder  les  données  informatiques  ou  papier 

•  Créer  des  plans  de  reprise  en  cas  de  défaillance 

•  Documenter  les  expériences  passées 

•  Former. . .  former  et  former! 

Il  faut  se  rappeler  aussi  d'une  notion  évidente:  le  traitement  du  risque  lui-même  peut 
engendrer  des  risques  humains  ou  matériels.  La  défaillance  ou  l'inefficacité  des  mesures  de 
traitement  envisagées  peuvent  constituer  un  risque  significatif.  Pour  s'assurer  que  les  mesures 
restent  efficaces,  la  surveillance  doit  faire  partie  intégrante  du  plan  de  traitement  du  risque  et 
une  personne  à  plein  temps  doit  y  être  consacrée  pour  les  grands  projets  ou  pour  le  quotidien 
d'une  entreprise  de  plus  de  100  personnes.  Des  sessions  de  formation  de  prévention  au  risque 
("préventique")  doivent  être  menées  au  moins  une  fois  par  trimestre  aux  ressources  afin 
qu'elles  assimilent  les  règles  d'or  dans  le  domaine. 

Nous  allons  maintenant  aborder  ci-après  une  technique  simple  permettant  de  se  couvrir  de 
manière  très  correcte  des  risques  et  ce  de  manière  quantifiable  et  professionnelle. 

Personnellement  à  chaque  fois  que  j'ai  utilisé  cette  technique  sur  des  projets  pour  lesquels  ma 
direction  me  donne  le  temps  de  faire  les  calculs,  je  n'ai  jamais  dépassé  ni  les  délais,  ni  les 
coûts  (bon  évidemment  il  y  a  statistiquement  un  facteur  chance  qu'il  ne  faut  jamais  négliger!). 

8. 6. 3. 3. 6. 2  Estimation  du  temps  (et  des  coûts) 

Il  arrive  très  fréquemment  que  la  durée  d'une  tâche  (ainsi  que  l'estimation  de  ses  coûts)  ne  soit 
pas  certaine,  ce  qui  entraîne  une  incertitude  sur  la  durée  totale  du  projet. 

L'une  des  solutions  est  de  considérer  que  la  durée  de  la  tâche  est  une  variable  aléatoire 
(considérée  comme  indépendante  par  les. . .  euh. . .  spécialistes  dans  le  domaine)  qui  suit  une 
loi  de  probabilité  donnée.  L'ensemble  du  projet  n'est  plus  alors  construit  alors  sur  la  base  d'un 
analyse  PERT  mais  PNET:  Probabilistic  Network  Evaluation  Technique. 
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Remarque :  En  théorie,  pour  minimiser  le  risque,  la  durée  de  l'organisation  et  la  planification 
d'un  projet  doit  converger  vers  la  durée  du  projet  lui-même!  Pensez  au  projet  scientifique  du 
télescope  Hubble  qui  a  début  en  1970,  a  été  concrétisé  par  l'envoi  en  orbite  en  1985  (15  ans!) 
et  qui  fonctionne  encore  au  top  de  ses  performances  encore  en  2012  (après  quelques 
réparations)  soit  25  ans  après! 

Cette  approche  est  purement  quantitative.  Nous  refusons  dans  ce  support  l'approche 
qualitative  qui  est  intuitivement  accessible  à  un  enfant  et  qui  concerne  en  la  procédure 
suivante  (prise  de  l'aide  de  MS  Project  expliquant  le  fonctionnement  de  Project  Serveur  en 
même  temps): 

Un  risque  est  un  événement  ou  une  condition  probable  qui,  s'il  se  produisait  réellement,  aurait 
un  impact  négatif  sur  un  projet.  Les  risques  diffèrent  des  problèmes  en  ce  que  ces  derniers 
vont  se  produire  certainement  ou  qu'ils  se  produisent  actuellement.  Un  risque  peut  devenir  un 
problème  s'il  n'est  pas  prévenu  efficacement. 

Le  processus  de  gestion  des  risques  (que  certaines  entreprises  qui  ont  des  énormes  marges 
considèrent  comme  inutile. . .)  consiste  à  identifier,  analyser  et  supprimer  les  risques  d'un 
projet  de  sorte  qu'ils  ne  se  transforment  pas  en  problème  avec  toutes  les  conséquences 
nuisibles  pour  le  projet  que  cela  peut  impliquer. 

La  fonction  de  gestion  des  risques  permet: 

1.  D'énumérer  les  risques  liés  à  un  projet  ; 

2.  D'évaluer  l'impact  des  risques  sur  vos  projets  ; 

3.  De  planifier  des  stratégies  de  contingence  et  de  limitation  ; 

4.  D'associer  des  risques  à  des  tâches  ; 

5.  D'associer  des  risques  à  des  problèmes  ; 

6.  D'associer  des  risques  à  des  documents  ; 

7.  D'associer  des  risques  à  des  projets  ; 

8.  D'associer  des  risques  à  d'autres  risques  ; 

9.  De  faire  en  sorte  que  les  risques  soient  approuvés  par  un  responsable  ; 

10.  De  demander  à  ce  que  des  alertes  de  risques  vous  soient  envoyées  par  courrier 
électronique. 

Cependant  les  questions  auxquelles  sera  confronté  le  gestionnaire  de  projets  professionnel  de 
haut  niveau  seront  du  type: 

-  Quelle  est  la  probabilité  que  l'activité  X  soit  finie  avant  la  date  y 
Quelle  est  la  probabilité  qu'elle  devienne  critique? 

-  Quelle  est  la  probabilité  de  respecter  la  date  de  réalisation  du  projet? 
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Pour  répondre  à  ces  questions  il  existe  de  multiples  techniques  mais  voici  celle  recommandées 
par  le  PMBOK: 

-  Le  jugement  d'expert 

-  L'estimation  par  analogie  (sur  des  projets  passés) 

-  L'estimation  par  trois  points37  (par  scénarios  optimiste,  attendu  et  pessimiste) 

-  L'estimation  paramétrique  (ce  que  nous  allons  étudier  plus  bas) 

-  La  planification  par  réserve  mathématique  (nécessitant  au  préalable  d'avoir  fait 
l'estimation  paramétrique) 

L'estimation  paramétrique  se  base  donc  sur  l'analyse  statistique  (ajustement  par  tests  de 
goodness  of  fit  avec  tests  d'Anderson-Darling  ou  Kolmogorov-Smirnov)  des  données  passées 
ou  l'utilisation  de  lois  de  distributions  basées  sur  le  jugement  d'expert  comme  les  distributions 
gaussienne,  triangulaire,  bêta  recommandées  par  le  PMBOK.  Ensuite  des  simulations  par 
millions  sont  exécutées  en  utilisant  la  méthode  de  Monte-Carlo  ou  Latin  Hypercube.  Il  est 
aussi  possible  d'utiliser  Bootstrapping  si  nécessaire  pour  déterminer  les  paramètres  des  lois. 
Mais  la  plus  connue  en  gestion  de  projets,  et  parce  qu'elle  est  aussi  incluse  dans  MS  Project, 
est  la  loi  de  distribution  Bêta. 

La  simulation  est  une  technique  utilisée  par  le  responsable  de  projet  expert,  exactement 
comme  le  fait  le  sportif  d'élite  avant  une  compétition  importante  (il  simule  la  compétition 
dans  sa  tête  de  nombreuses  fois...  raison  pour  laquelle  des  sportifs  sont  souvent  invités  dans  ls 
entreprises  pour  faire  des  séminaires).  L'oubli  de  simuler  un  projet  l'amène  le  plus  souvent  à 
son  échec...  C'est  un  des  raison  pour  lesquels  les  pilotes,  les  militaires,  les  policiers,  les 
pompiers,  les  urgentistes,  les  financiers,  les  astronautes,  les  ingénieurs  et  les  chercheurs  ont 
l'habitude  de  simuler  les  modèles  et  les  situations  pour  mieux  y  faire  face  lorsqu'elle  aura 
vraiment  lieu. 

Remarque:  Si  vous  voulez  appliquer  avec  le  plus  de  rigueur  possible  les  outils  qui  vont 
suivre,  il  vous  faudrait  une  base  de  données  avec  les  tâches  incluant  les  informations 
suivantes:  nom  des  tâches,  catégorie,  métier,  nom  de  l'exécutant,  nom  du  créateur  de  la  tâche, 
durée  estimée  (vendue),  durée  effective  (réelle),  coût  estimé  (vendu),  coût  effectif  (réel). 

Ainsi,  grâce  à  une  base  de  données  de  ce  type,  vous  pourrez  déterminer  la  loi  de  statistique  à 
utiliser  objectivement  relativement  aux  technique  que  nous  allons  présenter  (le  résultat  des 
analyse  mène  souvent  à  des  conclusions  catastrophiques  au  niveau  de  la  qualité  du 
management  d'une  organisation...). 

8.6.33.6.2. 1  Loi  Bêta  (approche  paramétrique) 

Cette  approche  classique  date  de  1962  et  est  due  à  C.E.  Clark  suite  à  l'étude  d'une  énorme 
base  de  données  de  tâches  et  elle  est  recommandée  par  le  PMI  (raison  pour  laquelle  je  me 
limite  à  présenter  cette  loi  particulière).  Ce  n'est  évidemment  de  loin  pas  la  seule  loi  en 
modélisation  (dont  attention  à  ne  pas  utiliser  que  celle-ci  bêtement  et  simplement!),  mais  je 
renvoie  le  lecteur  à  mon  ouvrage  sur  les  mathématiques  appliquées  s'il  souhaite  approfondir  le 
sujet. 

Ses  principes  sont  les  suivants: 


37  Voir  mon  livre  sur  MS  Project  où  un  exemple  pratique  d'estimation  par  trois  points  est  fait  avec  le  logiciel 
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Vincent  ISOZ 


La  durée  de  chaque  tâche  élémentaire  et  non  décomposable  du  projet  est  considérée  comme 
aléatoire  et  la  distribution  Bêta  est  systématiquement  utilisée.  Les  paramètres  de  cette  loi  que 
nous  allons  démontrer  sont  déterminés  moyennant  une  hypothèse  de  calcul  assez  forte,  à 
partir  des  valeurs  extrêmes  a  et  b  que  la  durée  d'exécution  peut  prendre,  et  du  mode  M0 .  Il 

suffit  donc  de  poser  les  trois  questions  suivantes:  "quelle  est  la  durée  minimale?",  "quelle  est 
la  durée  maximale?",  et  "quelle  est  la  durée  la  plus  probable?",  pour  obtenir  respectivement 
les  paramètres  a,b,M0 ,  qui  permettent  ensuite  de  calculer  la  moyenne  et  la  variance  de  cette 
durée  aléatoire. 

Ensuite,  nous  déterminons  le  chemin  critique  du  projet  (par  la  méthode  des  potentiels  métra 
supposée  connue  par  le  lecteur),  en  se  plaçant  en  univers  certain  et  en  utilisant  les  durées 
moyennes  obtenues  avec  la  loi  Bêta,  ce  qui  permet  de  trouver  le(s)  chemin(s)  critique(s). 

Enfin,  nous  nous  plaçons  en  univers  aléatoire  et  la  durée  du  projet  est  considérée  comme  la 
somme  des  durées  des  tâches  du  chemin  critique  précédemment  identifié.  Nous  utilisons  alors 
le  théorème  de  la  limite  centrale  (rappelons  que  ce  théorème  établit,  sous  des  conditions 
généralement  respectées,  que  la  variable  aléatoire  constituée  par  une  somme  de  n  variables 
aléatoires  indépendantes  suit  approximativement  une  loi  normale,  quelles  que  soient  les  lois 
d'origine,  dès  que  n  est  assez  grand)  pour  approximer  la  loi  de  distribution  de  probabilités  de 
la  durée  d'exécution  du  projet. 

Remarque :  Le  PMBOK  ne  donne  qu'une  formulation  approximative  et  simplifiée  des  calculs 
qui  vont  suivre  comme  le  mentionne  John  Schuyler  dans  la  deuxième  édition  de  son  ouvrage 
Risk  and  Decision  Analysis  du  PMI  comme  le  montre  la  capture  d'écran  suivant: 


In  PERT.  we  obtain  estimâtes  cf  completion  time  for  each  activity.  Tra- 
ditionally,  these  are  in  the  forni  cf  three  points: 

Optimistic  completion  time  (L) 

Pessimistic  completion  time  (H) 

□  Most  Likely  (mode)  completion  time  (M). 

Here  are  the  traditional  formulas  for  the  statistics  (using  "moment 
methods"  cf  Chapter  l)_The  mean  time  to  complété  a  ta.sk  is: 

L+4M  +  H 


Tlie  standard  déviation  cf  the  completion  time  is  approximately: 

H-L 

6 

These  formulas  approximate  the  statistics  for  a  beta  distribution.  Tlien. 
the  project  lias  a  mean  completion  time  for  activâtes  along  the  CP: 


L'espérance  mathématique  (ainsi  que  la  variance)  de  cette  loi  normale  se  calcule  comme  la 
somme  des  espérances  mathématiques  (ou  des  variances)  de  chaque  durée  des  tâches  du 
chemin  critique  (voir  mon  livre  de  Mathématiques  Appliquées)  tel  que: 


(  k  \ 

Ex 

v  i= i  y 
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et  dans  le  cas  particulier  où  les  variables  sont  linéairement  indépendantes,  la  covariance  étant 
nulle  (voir  le  chapitre  de  Statistiques  de  mon  livre  sur  les  Mathématiques  Appliquées)  nous 
avons  aussi: 


f  k 


V 


V  i= 1 


Rappelons  que  nous  avons  vu  lors  de  notre  étude  des  chapitres  de  Statistiques  et  du  Calcul 
Différentiel  Et  Intégral  de  mon  livre  sur  les  Mathématiques  Appliquées  que: 

B(p,  q )  =  r(j7)'r(^)  =  f  tp~l  (1  -  t)q~l  dt 
T(p  +  q)  J 

Équation  1  Fonction  Bêta 


et: 


r(jc+i)  =  jc-r(jc) 

Equation  2  Fonction  Gamma 

Si  deux  variables  aléatoires  indépendantes  X,  Y  suivent  des  lois  gamma  de  paramètres 

X 

a-l  =  a  et  b  - 1  =  y  respectivement,  la  variable  T  =  — — —  suit  une  loi  que  nous  appelons 
"loi  bêta  de  première  espèce"  (voir  mon  livre  de  Mathématiques  Appliquées). 

La  fonction  de  distribution  de  T  est  alors: 


1  -L[0,l] 


\ta(X-t)rdt 


Equation  3  Loi  Bêta 

Pour  un  intervalle  [a, b]  quelconque,  nous  obtenons  la  forme  plus  générale 


p  (x)  (x-a)a(b-xY 

r a, b  W  —  i  va, b] 

(b  -  a)a+r+l  |f“  (1  -  t)r  dt 
0 

Vérifions  que  nous  ayons  bien: 

b  \  b 

| Pa  b  (x)dx  = - - - J(x  -  a)a  ( b  -  x)r  dx  =  1 

û  (b-a)a+r+1\ta(l-t)rdta 

o 

Par  le  changement  de  variable: 
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a 


u  = 


b-a 


du  = 


b-a 


-dx  et  1  -  u  =  I  - 


■a 


b- 


b-a  b-a 


nous  obtenons: 


1  b 

»  J«*  -  a)u)a  (b  -  x)r  (b  -  a)du  J ua(b-x)rdu 

î  Kt  W*  =  - r - =  — — ; - 

"  (b  -  a)a+r+1 1  (1  -  t)Y  dt  (b  -  a)r  jta  (l-t)r  dt 

0  0 


1 

j  j  j*w“(l-u)r<iM  =  1 

j>(l-Or^  jV(i-or<fr° 

0  0 

Déterminons  maintenant  l'espérance: 


(Z7-a)a+r+1Jta(l-0r^û 


o 


Toujours  avec  le  même  changement  de  variable  nous  obtenons: 


/a  =  |  x  •  Pa  b  (x)dx  =  - - |(a  +  u(b  -  a))-  ua  (1  -  u)r  du 

a  \taa-t)rdt° 

0 


=  a  +  - — — — — —  |  ua+i  (1  -  u)7  du  =  a  +  (b-a)- 

\ta(X-tYdt° 

0 


B(a  +  2,  y  + 1) 
B(a  + 1, 7  + 1) 


Or: 

B(a  +  2,y  +  ï)  _  T(a  +  2)  •  n>  + 1)  T(a  +  7  +  2) 

£(<2  +  l,7  +  l)_  T(a  +  y  +  3)  '  T(a  + 1)  •  T  (y  + 1) 

_  r(a  +  2)  T(a  +  y +  2)  _  (a +  ï)(a)T(a)  T(a  +  y  +  2) 
T  (<2  +  ^  +  3)  T  (<2  +  1)  T  (<2  +  ^  +  3)  crT  (<2) 

_  (a  +  V)(a)T(a)  T(a  +  y  +  2)  _  a  +  l 
(a  +  7  +  l)T(a  +  r  +  2)  <2T(a)  a +  7 +  2 

Donc: 


ju  =  a  +  (b-a)- 


oc  + 1 
<2  +  7  +  2 
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Calculons  maintenant  la  variance  en  utilisant  la  formule  d'Huygens  démontrée  plus  haut: 


VÇX)  =  EÇX2)-EÇX)2 


Calculons  d'abord  EÇX2) . 


EÇX2)  =  \x2  -PabÇx)dx  = 


-  jx2  -(x-a)a  Çb-x)r  dx 


Çb-a)a+r+1jtaÇl-t)rdta 
o 

Toujours  par  le  même  changement  de  variable  nous  obtenons, 

1  1 

E(X2)  =  - - J  (a2  +  u2Çb-a)2  +  2 a  -uÇb  -  a)^ua  (1  -u)r  du 

\taÇl-t)rdtQ 


2^  (b -a) 

—  Cl  + 


BÇa  + 


2  1 

^ - B(a  +  3,y  +  l)+  ,  2a^~a)  |V+1(l-Mf/fa 

1,  y  + 1)  /•  n 

\taa-tydt° 


CX +1 

-2 a(b-a) - (cf.  calculs  précédents) 

a+y+2 


2,0/7  \  a  +  l  ,  n  \i  BÇa  +  3,  y  +  1) 

=  a  +2  aÇb-a) - \-Çb-a) 


a  +  y  +  2 


BÇa  + 1,  y  + 1) 


Or: 

BÇa +  3,y +  V)  _TÇa +  3) -TÇy +  \)  r(a  +  y  +  2)  _  (a  +  2)(a  +  l) 

B{a  +  \,y  +  1)  TÇa  +  A  +  4)  T(a  +  l)r(y  +  l)  Ça  +  A  +  3)Ça  +  A +  2) 

Donc: 


E(X2)  =  a2  +2a(b-a)  ^  +  1  +  Çb-ci)2 

a  +  y  +  2 


Ça  +  2)(a  + 1) 

Ça  +  A  +  3  )(a  +  A  +  2) 


Pour  finir: 


VÇX)  =  a2  =EÇT2)-EÇX)2  =EÇT2)-jU2 


?  n  a  +  1  .9 

=  û  +2  aÇb-a) - \-Çb-a ) 


«  +  2 


a  + 1 


a  +  y  +  2 


a  +  y  +  3  a+y+2 


Æ  +  (è  -  fl)  • 


a  +  1 
a  +  y  +  2 


=  Çb-a)2 


a  + 1 
a  +  y  +  2 


a  + 1 


a  +  2 

va+y+3  a+y+2 


Çb-a)2  (a  +  l)(y  +  l) 
(a  +  y  +  2)  (a  +  y  +  3) 


Calculons  maintenant  pour  le  "module"  M0  de  cette  loi  de  distribution.  M0  est  par  définition 
le  maximum  global  de  la  fonction: 
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p  ( x-a)a(b-xY 

ra,b\A)~  1  L[a,b] 

C b-a)a+r+l\ta(l-tYdt 
o 

Il  suffit  pour  le  calculer  de  résoudre  l'équation: 

(*)_  Q 

dx 

Après  dérivation  nous  obtenons: 

a{x  -  a)a~x  ( b  -  x)r  -  y(x  -  a)a  (b  -  x)7~l  =  0 


en  divisant  par  (x-a)a  x(b-x)r  1  nous  avons: 

a(b  -  x)  -  y{x  -a)  =  0 


c'est-à-dire: 


x  =  M0  = 


ab  +  ya 
a  +  y 


Maintenant,  le  lecteur  aura  remarqué  que  la  valeur  a  est  la  valeur  la  plus  petite  et  la  b  la  plus 
grande.  Entre  deux  il  y  a  donc  le  mode  M0 .  En  gestion  de  projets,  cela  correspond 

respectivement  aux  durées  optimiste  t0 ,  pessimiste  tp  et  attendu  tv  d'une  tâche. 


Ensuite,  nous  imposons  une  hypothèse  assez  forte: 

a  =  2  +  yfï, y  =  2-  V2  ou  a  =  2- -^2, y  =  2  +  V2 
Ce  qui  implique  que  nous  ayons: 

ab+ya  _  (2  +  V2)è  +  (2- ^a  2b+^2b  +  2a-yf2a  _  2(a  +  b)  +  ^2{b  -  a) 

Mn  —  -  —  -  —  -  —  - 

a+y  4  44 


Équation  4  Mode  Loi  Bêta 


ainsi  que: 


(b-a)2  (a  +  ï)(y  +  l) 
V(X)  =  — - — IM. - L 

(a  +  y +  2)  (a  +  y +  3) 
Ce  qui  s'écrit  classiquement: 


(b  -  a)2  (4 +  2-  2  +  2  + 1) 
7  •  62 


C b-a Ÿ 
6 2 
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Et  finalement: 


V(T)  =  <j  (T)  = 


1  t-r\  _  b) 


Équation  5  Variance  Loi  Bêta 


E(X)  =  a  + 
6a  +  2b  + 


«  +  1  6a  +  (Z?  —  cb)(2  +  \[2  + 1) 

{b  —  a) - = - 

«+7+2  6 

■\ Jlb  +  b -2a-  \[2a  -  a  5  a  +  a  +  b  +  b  +  s[2 b  +  b-2a-  \f2a  -  a 


6  6 
a+b  2a  +  2b  +  (b  -  a)y/2  a  +  b  4M0  a  +  4M0+b  tQ  +  4tv  +  tp 
6  +  6  ~  6  +  6  ~  6  _  6 


Equation  6  Espérance  Loi  Bêta 


On  remarque  une  chose  que  contrairement  à  ce  qui  est  écrit  dans  certains  ouvrages  du 
PMI/PMP  la  valeur  modale  n'est  pas  toujours  plus  petite  que  l'espérance  dans  le  cas  de  la  loi 
bêta  (et  ce  même  dans  le  cas  de  la  majorité  des  lois  asymétriques)!!!  Au  contraire!  Comme 
quoi  il  ne  fait  pas  bon  ménage  de  laisser  des  non  scientifiques  enseigner  ou  faire  de  la  gestion 
de  projets... 

Les  deux  dernières  expressions  de  la  variance  et  de  l'espérance  sont  celles  que  vous  pouvez 
trouver  dans  n'importe  quel  livre  de  gestion  de  projets  (sans  démonstration  bien  sûr  et 
partiellement  faux. . .  !). 

Remarque :  La  durée  optimiste  doit  vraiment  être  considérée  comme  la  durée  pour  laquelle  il 
est  impossible  d'être  plus  rapide.  Inversement,  la  durée  pessimiste  doit  vraiment  être 
considérée  comme  la  durée  qui,  si  dépassée,  la  tâche  ou  le  projet  doit  être  abandonnée  (quel 
que  soit  le  projet  et  les  coûts  déjà  investis,  si  vous  n'arrivez  pas  à  avancer  vous  serez  bien 
obligé  d'abandonner  un  jour  ou  l'autre!  !  !). 
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Comme  nous  pouvons  le  voir,  la  loi  Bêta  à  une  queue  épaisse  sur  la  borne  droite.  Ce  qui 
signifie  que  nous  privilégions  en  matière  de  probabilités  le  retard  plutôt  que  le  travail  dans  les 
temps. 

Nous  définissons  aussi  le  "risque  d'action"  par  le  rapport  dont  l'interprétation  est  laissée  aux 
responsables  de  projet  et  au  client  (humm. . ..): 


R(T,)  = 


Equation  7  Risque  d’action 


Supposons  cette  loi  valide  puisque  maintenant  argumentée. 

Exemple: 

Soit  di  la  durée  des  tâches  d'un  chemin  critique  composé  des  tâches  B,D,F,G  d'un  projet 

donné  et  le  choix  suivant  pour  les  durées  optimistes  pessimiste  et  attendues  de  chaque  tâche 
respectivement  (choix  complètement  empirique  de  coefficient  pour  simplifier  l'exemple!): 

to(T,)  =  0-7-4  tr(T,)  =  \.2-d,  tv{T,)  =  d, 


Nous  imaginons  que  les  tâches  critiques  sont  telles  que  leurs  durées  attendues  sont  (choix 
complètement  empirique  pour  simplifier  l'exemple!): 

T B  =1'Td  =  12, Tf  =6,Tg  =2 


En  déduire: 

1.  La  durée  probable  (espérance)  t?t ,  l'écart-type  g  et  la  valeur  modale  selon  le  PMBOK 

2.  La  durée  de  chacune  des  tâches  avec  un  niveau  de  confiance  de  95% 

3.  La  probabilité  cumulée  que  chaque  tâche  se  termine  dans  le  temps  attendu. 

4.  La  durée  totale  du  chemin  critique  et  son  écart-type  (toujours  selon  le  PMBOK) 

5.  La  probabilité  cumulée  que  le  projet  soit  terminé  avant  27  jours. 

6.  Calculez  la  durée  totale  du  projet  avec  1  chance  sur  20  seulement  de  la  dépasser. 
Solutions: 

1.  Sachant  que  selon  le  PMI  (méthode  des  trois  points) 

E(X)  =  —  +4fy  +^p  =(pr 


38 


38  Référentiel  de  Gestion  de  projets:  Project  Management  Body  of  Knowledge 


Ingénierie  de  Gestion  de  projets 


306/547 


et: 

(7(T)  =  ]j^^  =  ^V(fj 

et: 

A/f  _  +  V2 (tp  —tQ) 

M°  “  4 

Nous  obtenons  après  application: 

tPr(rB)  =  6.88  tPr(rD)  =  11.8  tPr  (tf  )  =  5.9  fft(rG)  =  1.96 
<t(Tb)  =  0.583  o-(rD)  =  l  <j(Tf)  =  0.5  o-(rG)  =  0.166 

M0  =  7.88  M0  =  13.52  M0  =  6.76  M0  =  2.25 

2.  La  durée  de  chacune  des  tâches  avec  un  niveau  de  confiance  de  95%  ne  peut  être  obtenue 
formellement.  Il  faut  passer  par  exemple  par  MS  Excel  ou  @Risk  de  Palissade. 

Nous  avons: 

tP[  (Tb  \5%  =BETA.INVERSE(0.95;3+RACINE(2);3-RACINE(2);0.7*7;1.2*7)=8.25 
tPr  (Td  )95%  =  BETA.INVERSE(0.95;3+RACINE(2);3-RACINE(2);0.7*12;1.2*12)=14.14 
tPt  (Tf  )95%  =  BETA.INVERSE(0.95;3+RACINE(2);3-RACINE(2);0.7*6;1.2*6)=7.07 
tPt  (Tg  )95%  =  BETA.INVERSE(0.95;3+RACINE(2);3-RACINE(2);0.7*2;1.2*2)=2.35 

avec  un  logiciel  plus  performant  que  MS  Excel  nous  avons  pour  la  fonction  de  distribution  de 
la  tâche  B  où  nous  voyons  bien  sur  l'image  les  valeurs  calculées  précédemment: 
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Définir  une  distribution  peur  B7 
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Par  contre  nous  voyons  que  la  moyenne  donnée  par  le  logiciel  @Risk  ne  correspond  pas  à  la 
valeur  obtenue  à  l'aide  de  formule  donnée  par  le  PMBOK  (PMI)  qui  est  de  6.88  et  donc  sous 
évalue  de  manière  non  négligeable  la  vraie  espérance  mathématique. 

Au  fait  la  raison  est  simple  car  le  PMBOK  (PMI)  fait  une  erreur  en  confondant  la  valeur 
modale  et  la  valeur  attendue.  Nous  n'avons  en  l'occurrence  démontrés  dans  le  chapitre  de 
Statistique  que  nous  n'avons  pas: 


E(X)  =  —  +4f|/  +^p  =(pf 


mais: 


E(X)  = 


tn  +  4M  n  +  to 


6 


=  t. 


Pr 


et  vous  pouvez  vérifier. ...!!!  On  comprend  alors  mieux  aussi  pourquoi  nombre  de  projets 
échouent... 


3.  La  probabilité  cumulée  que  chacune  des  tâches  se  termine  dans  le  temps  attendu  ne  peut 
être  obtenue  formellement.  Il  faut  passer  par  exemple  par  MS  Excel  ou  @Risk  de  Palissade. 
Nous  avons  alors: 


P(Tb  <  7)  =LOI. BET A(7 ; 3  +  RACINE  (2);3-RACINE(2);0.7*7;1.2*7)=20.79% 


P(Td  <  12)=  LOI.BETA  (12;3+  RACINE  (2);3-  RACINE  (2);0.7*12;1.2*12)=20.79% 
P(Tf  <  6)  =  LOI.BETA  (6;3+  RACINE  (2);3-  RACINE(2);0.7*6;1.2*6)=20.79% 
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P(Tf  <  2)=  LOI.BETA  (2;3+  RACINE  (2);3-  RACINE(2);0.7*2;1.2*2)=20.79% 

Nous  voyons  donc  que  la  probabilité  cumulée  de  tomber  juste  dans  la  durée  estimée  par  le 
responsable  de  projet  est  assez  faible. . .  !  Alors  que  la  probabilité  de  tomber  sur  la  valeur 
Modale  est  bien  plus  grande!  !  ! 

4.  La  durée  estimée  du  chemin  critique  est  donnée  par: 

rf?  =  2X  (r)  =  26.54 


La  variance  du  chemin  critique  est  alors  (si  les  variables  aléatoires  sont  indépendantes 
rappelons  que  la  variance  d'un  somme  est  égale  à  la  somme  des  variances  quel  que  soit  la 
loi!): 


Vecst  =  (7])  =  Lô18=>  cr  =  V1-618  =  L27 


5.  Calculons  la  probabilité  pour  que  la  durée  du  chemin  critique  soit  inférieure  à  la  valeur  27. 
La  loi  de  Gauss  centrée  réduite  nous  permet  d'écrire: 

k'  =  izif  =  tlhaL  =  27  -  26.54  =  0  353 

<7  <7  1.27 

En  utilisant  MS  Excel  nous  avons  maintenant: 

=LOI.NORMALE.STANDARD(0. 35 3 )=63 .82% 

Donc  nous  avons  une  probabilité  cumulée  de  -64%  d'avoir  une  durée  inférieure  ou  égale  à  27 
jours! 

Nous  aurions  obtenu  le  même  résultat  avec: 

=LOI.NORMALE(27  ;26.54;  1 .27;  1)=63.82% 

6.  Nous  utilisons  pour  déterminer  la  durée  avec  une  couverture  du  risque  de  95%: 

=LOI.NORMALE.INVERSE(95%;26.54;1.27)=28.62 


Remarques: 

Rl.  Par  extension,  cette  technique  s'applique  bien  évidemment  aux  coûts  (s'ils  sont 
proportionnels  à  la  durée!) 

R2.  Rappelons  que  loi  de  Parkinson  affirme  que  «  le  travail  s'étale  de  façon  à  occuper  le 
temps  disponible  pour  son  achèvement  ».  Pensez-y!  !! 

Exercices: 

Appliquez  l'exemple  précédent  dans  MS  Project: 

1 .  Saisissez  les  tâches  critiques  et  leurs  relations 
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Vérifiez  leur  durée  minimale  dans  un  univers  certain 


3.  Activez  l'affichage  du  chemin  critique 

4.  Appliquez  le  PERT  probabiliste 

5.  Vérifiez  que  vous  ayez  aussi  environ  26.54  jours 

6.  Calculer  le  pourcentage  de  probabilité  d'être  inférieur  à  27  jours  dans  MS  Excel  avec 
la  fonction  NORMALDIST() 

7.  Personnalisez  la  vue  du  Gantt  standard  pour  faire  apparaître  dans  chaque  barre  de 
tâche  un  petit  trait  représentant  la  date  de  fin  pessimiste,  optimiste  et  probabiliste. 
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Remarque:  Dans  la  réalité,  que  l'on  utilise  la  loi  Bêta,  Triangulaire  ou  Uniforme  (qui 
nécessitent  toutes  au  moins  l'estimation  de  deux  durées  selon  le  retour  d'expérience),  une 
technique  qui  fonctionne  bien  pour  estimer  en  équipe  les  durées  optimistes  ou  pessimistes 
consiste  lors  d'une  réunion  à  faire  écrire  sur  un  bout  de  papier  à  chaque  ressource  son 
estimation  des  deux  paramètres  précités.  Le  responsable  de  projet  récupère  alors  les  papiers  et 
note  sur  un  tableau  la  chose  suivante: 


Tâche  A 

Optimiste 

Pessimiste 

Max 

3 

7 

Min 

6 

9 

Si  l'étendue  Max-Min  pour  chaque  estimateur  est  trop  grande,  l'équipe  doit  alors  discuter 
intensément  du  sujet  ou  fractionner  la  tâche  estimée  pour  réduire  le  biais  jusqu'à  ce  que  le 
biais  soit  acceptable.  Cette  manière  de  procéder  est  inspirée  de  ce  qu'on  appelle  le  "planning 
poker"  "  (puisque  chaque  ressource  masque  son  estimation  aux  autres)  qui  découle  du 
"Scrum"  de  la  méthode  "Agile.  À  la  différence  que  l'application  des  jeux  de  cartes  qu'on  peut 
acheter  sur  Internet  sont  inapplicables  dans  la  réalité  pour  de  grandes  équipes  de  projets  multi- 
sites  et  complexes. 

8.6.3. 3.6.2.2  Théorème  central  limite 

Lorsque  vous  travaillez  sur  un  projet  de  plus  d'une  centaine  de  tâches,  imaginons  que  les 
distributions  statistiques  sont  toutes  indépendantes  (car  vous  avez  construit  le  planning  afin 
que  cela  soit  le  cas),  d'espérance  et  de  variance  finie,  et  de  même  loi. 

Les  mathématiciens  ont  alors  démontré  via  un  théorème  fameux  appelé  "théorème  central 
limite"  (voir  mon  livre  sur  les  Mathématiques  Appliquées  pour  la  démonstration)  que 
l'ensemble  suivra  asymptotiquement  une  loi  Normale. 

Mais  dans  la  réalité,  via  une  simulation  de  Monte-Carlo,  les  tâches: 

1.  Ne  seront  pas  toutes  identiquement  distribuées 

2.  N'auront  pas  toute  une  variance  finie 

3.  Ne  seront  pas  toutes  indépendantes 

Le  support  de  la  loi  obtenue  sera  alors  certainement  borné  (à  gauche  et  à  droite  dans  le  temps 
et  dans  le  budget)  et  ne  suivra  par  une  loi  Normale! 

Je  recommande  cependant  par  retour  d'expérience  de  considérer  que  la  distribution  résultante 
de  la  simulation  comme  étant  une  distribution  continue  (il  faudra  la  déterminer  via  un  test 
statistique  d'ajustement)  dont  le  support  est  non  borné  à  droite  (semi-ouvert).  Ainsi,  même  si 
vous  avez  de  la  difficulté  à  estimer  la  durée  pessimiste  de  chaque  tâche,  le  résultat  final, 
contiendra  in  extenso  tous  les  imprévus  possibles  et  imaginables  puisque  le  temps  sera  non 
borné  à  droite. 

Dès  lors,  la  durée  de  votre  projet  (ou  son  budget  correspondant)  se  calculera  avec  l'intervalle 
de  probabilité  cumulée  entre  la  durée  optimiste  (idéale)  de  votre  projet  et  la  durée  pessimiste 
correspondant  à  l'appel  d'offre  ou  de  votre  forfait  stratégique  (dépendant  de  votre  réserve 
fractionnaire). 
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Attention!!!  N'oubliez  que  si  vous  utilisez  Monte-Carlo  (ou  Latin  Hypercube),  la  simulation 
prend  en  compte  les  tâches  dépendantes  ou  indépendantes  qu'elles  soient  de  variance  finie  ou 
pas.  Donc,  pour  résumer,  il  faut  toujours  être  très  prudent  quant  à  l'utilisation  bête  et  simple 
du  théorème  central  limite  dont  on  parle  dans  la  majorité  des  livres  comme  une  vérité  divine. 

8. 6. 3. 3. 6. 2. 2.1  Produit  et  somme  des  variables  aléatoires  normales 

La  loi  normale  n'est  par  ailleurs  pas  qu'un  outil  d'analyse  de  données  mais  également  de 
génération  de  données.  Effectivement,  cette  loi  est  une  des  plus  importantes  dans  le  monde 
des  multinationales  qui  recourent  aux  outils  statistiques  pour  la  gestion  du  risque,  la  gestion 
de  projets  et  la  simulation  lorsqu'un  grand  nombre  de  variables  aléatoires  sont  enjeu.  Le 
meilleur  exemple  d'application  en  étant  le  logiciel  CrystalBall  (pour  les  curieux). 

Dans  ce  cadre  d'application,  est-il  est  par  ailleurs  très  souvent  fait  usage  de  la  somme  de 
variables  aléatoires  suivant  des  lois  normales.  Voyons  comment  cela  se  calcule-t-il: 

Soit  X,  Y  deux  variables  aléatoires  indépendantes.  Supposons  que  X  suit  la  loi  N{/ux,c Jj)  et 
que  Y  suit  la  loi  N  (ju2 ,  <J2  )  ■ 


Rappel:  La  loi  normale  est  donnée  par: 


f(x) 


,  (*~/d2 

_ ! _ e  2 a2 

<T\f27T 


Alors,  la  variable  aléatoire  Z  =  X  +  Y  aura  une  densité  égale  au  produit  de  convolution  de 
fx  et  fY .  C'est-à-dire, 


)2  (.v-.ï-//2)2 


fz  O)  =  f  fx  (■ x)fY  0  -  x)dx  =  — — -  f 

J  /  77YT\  /T_  J 


2<r12 


2af 


2  7TCT  |  CT 

1  -  —y 


dx 


Pour  simplifier  l'expression,  faisons  le  changement  de  variable  t  =  x-jul  et  posons 
a  =  jul+  /u2~  s ,  (7  =  -yjof  +  crf  .  Nous  obtenons, 


(t+a)2 


<7t+- 


aa r 


-1  "l-0®  _  O  r-v  O  -i  +00 

fz(s)  =  ~ - Ie  ^  e  ^  dt  =  ~ - 

/  rrrr  rv  J  /  rrrr  rv  J 


2tkj  i  cj 9 

1  Zj  — c 


2tccj \  cj 9 

1  ^  —a 


2  2  2 

éraf  crf 


+- 


2  oftff 


dt 


acre 
at+ — 


1 


a 


2g}  cj1; 


2  TT G  ]  G  - 


-e2(j2  \  e  2  dt 


Nous  posons: 


Ingénierie  de  Gestion  de  projets 


312/547 


<Jt  + 


aa. 


u  = 


du 


■y/ZcTj  <7 2  dt  \fl<7x  g 2 


dt  = 


du 


Alors: 


iV 


aar 


fz  (,s)  _ 


1 


+00 


2  71  O  j  G  2 


92<j2 


Gt+- 


2g}  G2 


_  +00 


12  dt  = - 

2  no 


|  e  u  du 


2 

Sachant  que  J  e~u  du  =  \fïr  notre  expression  devient: 


2^2 


Équation  8  Convolution  2  Lois  Normales 


Nous  reconnaissons  l'expression  de  la  loi  normale  de  moyenne  //j  +  ju2  et  d'écart-type: 

cr  =  ^cr12  +cr| 

Par  conséquent,  X+Y  suit  la  loi: 

N(th+t* 2’V°i2  +cr2  ) 

Il  s'agit  aussi  ici  d'un  cas  simple  de  produit  de  convolution  dont  le  calcul  numérique  peut  être 
fait  à  la  main  à  partir  de  table  numériques.  Mais  quand  il  s'agit  de  convoluer  des  lois 
différentes  entre  elles  alors  il  faut  recourir  aux  méthodes  d'intégration  de  Monte-Carlo. 

8.6.3. 3.6.2.3  Méthode  de  Monte-Carlo  (approche  simulatoire) 

L'ordonnancement  est  une  simulation  sur  la  base  d'un  scénario  privilégié  pour  chacune  des 
tâches.  La  méthode  de  Monte-Carlo39  (souvent  appelée  "What-if  analysis")  permet  d'explorer 
plusieurs  ordonnancements  combinant  des  scénarios  différents  pour  les  tâches  du  projet  et 
conduit  à  une  analyse  probabiliste  de  certaines  informations  comme  la  durée  du  projet  ou  la 
probabilité  qu'une  tâche  a  d'être  critique  sans  que  soient  nécessaires  les  hypothèses  d'i.i.d. 
(indépendants  et  identiquement  distribuées). 


39  La  méthode  de  Monte  Carlo,  initialement  élaborée  par  Nicholas  Metropolis  et  Stanislaw  Ulam,  a  été  utilisée  en 
1940  pour  le  projet  Manhattan  aux  laboratoires  de  Los  Alamos.  Elle  fut  pour  la  première  fois  appliquée  à  l'étude 
du  transport  électronique  par  Kurosawa  en  1966  et  très  utilisée  depuis  dans  tous  les  domaines  scientifiques. 
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La  simulation  par  Monte-Carlo  peut  aussi  être  vue  comme  une  méthode  de  "stress-test",  c'est- 
à-dire  d'observer  ce  qu'il  advient  du  comportement  des  délais  et  du  budget  hors  comportement 
attendu. 

Une  présentation  détaillée  de  la  méthode  de  Monte-Carlo  peut  être  trouvée  sur  le  site 
personnel  de  votre  serviteur:  www.sciences.ch;  nous  nous  contenterons  ici  d'en  rappeler 
brièvement  les  fondements  et  d'en  illustrer  l'usage  sur  un  exemple  de  distribution  empirique 
de  probabilité.  Un  exemple  pratique  est  fait  lors  de  notre  étude  du  VBA  dans  MS  Project  avec 
comme  base  d'application  une  loi  triangulaire  (voir  mon  livre  sur  Microsoft  Office  Project). 

Supposons  que  nous  nous  intéressions  à  une  grandeur  X  qui  peut  être  la  durée  d'une  tâche,  le 
coût  d'un  contrat  de  sous-traitance  ou  tout  autre  phénomène  quantitatif  auquel  nous  nous 
intéressons. 

Il  faut  tout  d'abord  connaître  la  fonction  de  répartition  de  la  variable  X.  Une  méthode 
empirique  consiste  à  interroger  le  spécialiste  (ou  une  base  de  données  avec  les  tâches  des 
projets  passés)  sur  les  valeurs  possibles  que  peut  prendre  cette  variable  X  par  une  série  de 
question  du  type:  "quelle  est  la  probabilité  que  la  variable  X  prenne  une  valeur  inférieure  à 
x?",  pour  quelques  valeurs  bien  choisies  de  x.  Supposons  enfin  que  les  réponses  obtenues 
aient  été  les  suivantes40: 


P(X  <  3900)  =  0% 

P(X  <  4100)  =  20% 

P(X  <  4400)  =  40% 

P(X  <  4800)  =  60% 

P(X  <  4950)  =  70% 

P(X  <5100)  =  80% 

P(X  <  5200)  =  100% 

Nous  avons  alors  la  possibilité  de  construire  par  interpolation  la  fonction  de  répartition  avec  le 

tableau  correspondant  ci-dessous: 


40 


L'exemple  est  pris  de  l'ouvrage  "Gestion  de  projets"  de  Vincent  Giard  aux  (excellentes)  éditions  Economica 
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fi 

<*> 

T 

<*> 

xt 

f'i 

(*> 

Fi 

(*) 

*t 

1 

3  910 

26 

4  190 

51 

4  620 

76 

5  040 

2 

3  920 

27 

4  205 

52 

4  640 

77 

5  055 

3 

3  930 

28 

4  220 

53 

4  660 

78 

5  070 

4 

3  940 

29 

4  235 

54 

4  680 

79 

5  085 

s 

3  950 

30 

4  250 

55 

4  700 

80 

fTîôq 

6 

3  960 

31 

4  265 

56 

4  720 

81 

SÏÔS 

7 

3  970 

32 

4  280 

57 

4  740 

82 

5  110 

8 

3  980 

33 

4  295 

58 

4  760 

83 

5115 

9 

3  990 

34 

4  310 

59 

4  7X0 

84 

5  120 

10 

4  000 

35 

4  325 

60 

1 4  son 

85 

5125 

11 

4  010 

36 

4  340 

61 

4815 

86 

5  130 

12 

4  020 

37 

4  355 

62 

4  830 

87 

5135 

13 

4  030 

38 

4  370 

63 

4  845 

88 

5  140 

14 

4  040 

39 

4  385 

64 

4X60 

89 

5145 

15 

4  050 

40 

(  4  40(1 

65 

4  875 

90 

5  150 

16 

4  060 

41 

4  420 

66 

4  890 

91 

5  155 

17 

4  070 

42 

4  440 

67 

4  905 

92 

5  160 

18 

4  080 

43 

4  460 

68 

4  920 

93 

5  165 

19 

4  090 

44 

4  480 

69 

4JÜ. 

94 

5  170 

20 

45 

4  500 

70 

1 4  950  J 

95 

5175 

21 

4  ns 

46 

4  520 

71 

4965 

96 

5  180 

22 

4  130 

47 

4  540 

72 

4  980 

97 

5185 

23 

4  145 

48 

4  560 

73 

4  995 

98 

5  190 

24 

4  160 

49 

4  580 

74 

5  010 

99 

5  195 

25 

4  175 

50 

4  600 

75 

5  025 

100 

5  200 

En  encadré,  les  valeurs  prises  en  exemple  tout  à  l'heure 


La  fonction  de  répartition  du  tableau  ci-dessus  établit  une  correspondance  précise  entre  des 
probabilités  cumulées  et  les  valeurs  correspondantes  de  X  (que  les  statisticiens  appellent 
fractiles )  et  réciproquement.  Il  s'ensuit  que  si  nous  disposons  de  K  valeurs  équiprobables  de 
probabilités  cumulées  P(X  <  xk  ) ,  k  variant  de  1  à  A',  nous  disposons  également,  grâce  à  la 

fonction  de  répartition  de  K  valeurs  équiprobables  xk .  Cette  remarque  forte  simple  est  à  la  base 

de  la  méthode  de  Monte-Carlo.  Son  application  conduit  pour  une  simulation  de  K  =  50  valeurs 
de  X  à  partir  de  notre  extrait  de  table  de  nombres  au  hasard  ci-dessous. 


i 

Ft 

(%) 

j 

Fl 

(%) 

i 

(%> 

■  i 

4j 

4460 

18 

84 

$156 

3 S 

82 

5  i  i  6 

2 

64 

4860 

19 

64 

4860 

36 

12 

4020 

3 

58 

4760 

20 

60 

4800 

37 

42 

4440 

4 

92 

5160 

21 

97 

5185 

38 

49 

4580 

5 

32 

4280 

22 

66 

4890 

39 

86 

5130 

6 

0 

3900 

23 

2 

3920 

40 

1 

3910 

7 

38 

4370 

24 

34 

4310 

41 

19 

4090 

8 

41 

4420 

25 

90 

5150 

42 

8 

3980 

9 

8 

3980 

26 

61 

4815 

43 

95 

5175 

10 

58 

4760 

27 

61 

4815 

44 

31 

4265 

11 

21 

4115 

28 

81 

5105 

45 

66 

4890 

12 

78 

5070 

29 

92 

5160 

46 

41 

4420 

13 

91 

5155 

30 

75 

5025 

47 

83 

5115 

14 

40 

4400 

31 

40 

4400 

48 

62 

4830 

15 

93 

5165 

32 

74 

5010 

49 

82 

5110 

16 

6 

3960 

33 

42 

4440 

50 

5 

3950 

17 

26 

4190 

34 

24 

4160 
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Les  nombres  aléatoires  sont  obtenus  à  partir  d'une  table  de  nombres  au  hasard  (nombres 
aléatoires  ou  pseudo-aléatoires)  ou  d'une  fonction  génératrice  de  nombres  au  hasard: 


FABLE  NOMBRES  AL  H  ASAR1)  (extraits) 
21789  14093 


- : 

43645  89232 
61618  19275 
68136  06546 
74005  34558 
54437  88825 

01990  94762 
02404  42408 
^9253  71535 


00384  10858 
40744  22482 
04029  47946 
93779  96120 
07943  81795 

89926  84764 
67981  43684 
26149  35629 


12424  9860 1 
19526  27122 
01695  47720 
31709  13358 

19159  95355 
55467  47030 
87127  45581 


06268  46460 
19089  53 I 66 
42515  55048 
88646  73520 
04626  64838 

98213  17704 
42545  43920 
00185  01041 


97660  23490 
41836  28205 
23912  81105 
40050  90553 
92133  44221 

47400  30837 
11199  36521 
4666298897, 


Cette  table  de  nombres  au  hasard  permet  de  simuler  des  valeurs  équiprobables  de  probabilités 
cumulées:  si  nous  extrayons  des  séquences  de  2  chiffres  de  cette  table  (comme  illustré  ci- 
dessous  pour  10  valeur),  nous  obtenons  autant  de  nombres  équiprobables  à  deux  chiffres  qui 
seront  considérées  comme  autant  de  valeurs  équiprobables  de  probabilités  cumulées  (dans 
notre  cas:  43%,  64%,  58%,  92%,  32%,  0%,  38%,  41%,  8%,  58%).  Si  nous  désirons  travailler 
avec  une  précision  plus  grande,  il  suffit  de  prélever  des  séquences  de  n  chiffres  (n  >  2);  pour 
n= 3,  nous  obtenons  des  probabilités  exprimées  en  "pour  mille",  etc. 

Remarque:  Des  nombres  pseudo-aléatoires  peuvent  être  obtenus  par  la  suite  récurrente  ci- 
dessous: 


ui  =  frac 


0 


où  7z  =  3.14159265  et  le  terme  frac  signifie  que  l'on  prend  la  partie  fractionnaire  du  nombre 
obtenu. 

L'idée  d'appliquer  la  méthode  de  Monte-Carlo  à  la  gestion  de  projets  est  due  à  Van-Slyke 
(1963)  ;  l'analyse  d'un  grand  nombre  de  simulations  globales  du  projet  permet  de  tirer  des 
enseignements  généralement  impossibles  à  obtenir  de  manière  analytique.  Cette  approche 
peut  être  appliquée  périodiquement,  sur  la  base  des  tâches  non  terminées  ou  non  commencées. 

Une  fois  connues  les  distributions  de  probabilités,  il  ne  reste  plus  qu'à  utiliser  les  méthodes 
classiques  de  Monte-Carlo  pour  obtenir  par  simulation  des  durées  des  différentes  tâches  (c'est 
ce  que  l'ensemble  des  plugins  payant  de  MS  Projet  et  autres  dans  le  domaine  de  la  gestion  du 
risque  font).  L'analyse  d'un  grand  nombre  de  simulations  globales  du  projet  permet  de  tirer 
des  enseignements  généralement  impossibles  à  obtenir  de  manière  analytique.  Cette  méthode 
repose  sur  les  principes  suivants,  conduisant  à  l'établissement  du  tableau  ci-dessous: 
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tâche  i  (durée  q) 

duré<  minimale 
du  projet  pour 
la  simulation  k 

1 

2 

i 

n 

jeu  de  simulation  k 

1 

\ 

s 

»\ 

2 

*>2 

xh 

‘fi 

S 

i h 

... 

... 

... 

... 

... 

... 

k 

\ 

... 

... 

... 

•  •• 

... 

... 

K 

X  i 

... 

X; 

lK 

«K 

* 

cm>qofi 

mt/K 

m2/k 

m,/K 

m„/K 

1.  Nous  supposons  que  la  fonction  de  répartition  P(Xi  <  xt  )  de  la  durée  X i  de  la  tâche 

i  du  projet,  lequel  comporte  n  tâches  ( i  varie  donc  de  1  à  n),  est  connue  suite  à  un 
sondage  dans  l'entreprise,  une  analyse  de  l'historique  des  projets,  soit  dans  le  pire  des 
cas  au  choix  empirique  d'une  loi  de  répartition  connue  (gaussienne,  bêta,  Weibull,  chi- 
deux,  Student,  etc.) 

Un  exemple  correspondant  est  typiquement  la  loi  obtenue  précédemment  représentée 
dans  une  figure  par  son  tableau  et  diagramme  respectif 

2.  Nous  réalisons  K  jeux  de  simulations  du  problème  d'ordonnancement  ;  le  Æ-ème  jeu  de 
simulations  ( k  variant  de  à  1  à  K)  comporte,  pour  chacune  des  n  tâches  du  projet,  une 
simulation  xt  qui  constitue  une  réalisation  de  la  variable  aléatoire  X  j ,  durée  de  la 

tâche  i;  le  nombre  K  de  jeux  de  simulations  doit  être  suffisant  pour  que  nous  puissions 
obtenir  de  bonnes  estimations  des  informations  recherchées. 

3.  La  simulation  d'une  durée  x^  d'une  tâche  i,  pour  le  jeu  de  données  k  s'obtient  par 

l'utilisation  d'un  nombre  z,k  généré  aléatoirement  ;  ce  nombre  zt  s'interprète  comme 

un  tirage  aléatoire  d'une  valeur  de  la  fonction  de  répartition  de  la  durée  de  cette  tâche  i 
(un  nombre  à  2  chiffres  correspondant  à  une  probabilité  exprimée  en  %);  les  valeurs 
zt  sont,  par  construction,  équiprobables. 

4.  La  connaissance  de  la  fonction  de  répartition  de  la  durée  Xj  d'une  tâche  i  et  celle  de  la 
valeur  tirée  aléatoirement  d'une  probabilité  cumulée  zik  -  P (Xi  <  xt  )  permettent  de 

calculer  le  fractile  x{  ;  l'équiprobabilité  des  valeurs  tirées  zt  =  P(Xj  <  xt  )  entraîne 
nécessairement  l'équiprobabilité  des  K  durées  x,  pour  une  tâche  donnée 

5.  Nous  nous  ramenons  en  univers  certain  pour  chacun  des  K  jeux  de  simulations  du 
problème  (c'est-à-dire  chacun  des  ensembles  de  n  valeurs  du  k-ème  jeu  de  données 

k  variant  de  1  à  k)  ;  nous  calculons  pour  chaque  jeu,  la  durée  minimale  d'exécution  Dk 
du  projet  (ceci  est  un  calcul  non  trivial  de  type  P=NP. ..!!). 
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6.  L'analyse  statistique  des  K  jeux  de  résultats  obtenus  par  simulation  permet  d'obtenir 
trois  informations  qui,  contrairement  à  l'approche  de  la  loi  Bêta,  tiennent  compte  de 
tous  les  chemins  critiques  possibles  et  n'impose  de  contraintes  sur  le  nombre  de  tâches 
au  projet  (contrainte  liée  à  l'utilisation  du  théorème  de  la  limite  centrale).  Ces  résultats 
sont: 

a.  pour  le  projet:  une  estimation  de  l'espérance  (moyenne)  mathématique  de  la 
durée  minimale  d'exécution  du  projet41  excède  une  durée  donnée. 

b.  pour  chaque  tâche:  une  estimation  de  la  probabilité  que  cette  tâche  soit  critique 
(indice  de  criticité  de  la  tâche  noté  %critique  et  calculé  par  le  rapport  mi  /  K  - 
nombre  de  tâches  critiques  sur  tâches  non  critiques). 

Cette  démarche  simulatoire  ne  repose  pas  sur  d'autres  hypothèses  que  celles  relatives  au  choix 
des  distributions  de  référence  et  de  leurs  paramètres,  encore  qu'il  soit  tout  à  fait  possible  de 
partir  de  distributions  totalement  empiriques  (interpolations  linéaires  effectuées  sur  une 
fonction  de  répartition  définie  par  trois  à  cinq  points).  Le  choix  d'une  distribution  n'est  guère 
facile,  aucun  argument  théorique  sérieux  ne  militant  en  faveur  de  l'une  ou  l'autre.  Tout  au  plus 
peut-on  signaler  qu'au  départ  le  choix  est  à  effectuer  entre  une  distribution  unimodale  (loi 
Bêta,  loi  normale,  loi  triangulaire,  etc.)  ou  sans  mode  (loi  uniforme).  Le  choix  à  priori 
systématique  d'une  distribution  unimodale  pose  un  problème,  pour  un  responsable,  à  qui  l'on 
demande  la  valeur  du  mode  de  la  tâche  qu'il  gère,  il  y  a  autant  de  chances  d'observer  n'importe 
quelle  valeur  comprise  dans  un  intervalle,  car  cette  question  n'a  alors  aucun  sens!  Nous 
pouvons  toujours  rajouter  qu'il  n'y  a  aucune  raison  d'imposer  le  même  modèle  statistique  à 
toutes  les  tâches. 

Voici  un  exemple  du  plug-in  Risk+  (C/S  Solutions)  qui  était  disponible  pour  MS  Project  à 
mes  débuts  et  qui  appliquait  Monte-Carlo: 


41  De  nombreux  travaux  montrent  qu'en  général,  l'espérance  mathématique  de  la  durée  du  projet  est  supérieure  à 
la  valeur  trouvée  en  univers  certain. 
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Figure  30  Choix  des  distributions  dans  Risk  + 


Figure  31  Convergence  de  la  modélisation  dans  Risk+ 
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Risk  Analysis  Entry  Form 
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Figure  32  Formulaire  de  Risk  + 
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Figure  34  Distribution  probabiliste  de  la  date  de  complétude  du  projet  (Risk+) 


Remarque:  Les  logiciels  de  simulation  probabiliste  du  risque  sur  la  planification  font  (et  c'est 
logique  de  mon  point  de  vue)  abstraction  des  contraintes  sur  les  tâches  du  type  Doit  finir  le 
( Must  Finish  On)  ou  Ne  pas  finir  plus  tard  que  le  ( Finish  no  later  than )  ainsi  que  Ne  doit  pas 
commencer  plus  tard  que  le  ( Start  No  Later  than).  Par  contre,  ces  logiciels  voient  les 
contraintes  du  type  Ne  doit  pas  commencer  plus  tôt  que  le  ( Start  no  earlier  than).  Doit 
commencer  le  ( Must  Start  On). 


Depuis  2005  je  préfère  travailler  sur  @Risk  de  Palisade  (la  version  4  puisque  les  nouvelles 
versions  obligent  de  passer  par  Excel  ce  qui  me  fait  horreur!)  qui  propose  plus  de  possibilités 
plus  étendus  et  surtout  un  outil  de  GOF  (Goodness  Of  Fit)  intégré  avec  les  tests  d'ajustement 
du  Chi-2,  de  Kolmogorov-Smimov  et  d'Anderson-Darling  (cela  n'empêche  pas  qu'il  faut 
vérifier  les  ajustements  proposés  avec  d'autres  algorithmes  dans  des  logiciels  tiers  comme 
Minitab,  SPSS  ou  autres...  sinon  gare  aux  surprises!).  Voyons  un  exemple  simple  où  nous 
nous  baserons  sur  les  hypothèses  suivantes: 

1.  Les  durées  des  tâches  sont  indépendantes  mais  pas  identiquement  distribuées 

2.  Les  durées  des  tâches  sont  basées  sur  le  REX  (base  de  données  historique  des  projets) 

3.  Il  n'y  pas  de  relation  analytique  connue  entre  la  durée  réelle  et  attendue  des  tâches 

4.  Les  tâches  qui  avaient  été  omises  (oubliées)  dans  les  projets  passés  ont  une  durée 
attendue  nulle  mais  afin  de  simplifier  l'exemple,  nous  ignorerons  leur  existence  (ce  qui 
est  évidement  infiniment  dangereux) 

Dans  l'exemple  réel  que  j'ai  repris  d'une  entreprise  en  2012,  nous  avons  à  notre  disposition 
environ  l'800  tâches  d'un  petit  projet  dont  nous  avons  les  noms  des  employés  (codés),  les 
noms  de  départements  réels  (il  n'y  a  qu'un  responsable  de  projet  par  département),  la  durée  qui 
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avait  été  estimée,  la  durée  réelle  qui  a  eu  lieu.  Donc  nous  n'avons  rien  concernant  les  coûts  ce 
qui  nous  oblige  à  nous  restreindre  à  la  modélisation  du  temps  (et  donc  seulement 
indirectement  aux  coûts  honoraires). 


Pour  information,  l'entreprise  en  question  n'avait  pas  son  équipe  de  management  qui  était  sous 
contrôle  statistique  (Lean  Six  Sigma),  alors  que  les  équipes  de  production,  elles  l'étaient... 
C'est  une  absurdité!  Il  est  facile  aux  cadres  d'imposer  des  mesurages  de  performances  à  la 
main  d'oeuvre  mais  il  faut  que  la  direction  leur  impose  les  mêmes  contraintes  afin  d'éviter  les 
échecs  et  dépassement  de  délais  et  coûts  des  projets.  Vous  verrez  par  ailleurs  que  dans 
l'exemple  que  nous  allons  faire,  il  apparaît  nettement  que  les  responsables  de  projets  estiment 
les  temps  n'importent  comment  (en  réalité  ils  ne  communiquaient  pas  avec  leurs 
exécutants...). 


Si  l'entreprise  avait  son  management  sous  contrôle  statistique  et  faisait  donc  aussi  du  lean  au 
niveau  des  cols  blancs,  nous  devrions  avoir  une  relation  linéaire  entre  le  travail  réel  (Real 
Work )  et  le  travail  estimé  (Estimated  Work).  Si  nous  faisons  rapidement  cette  analyse  avec 
MS  Excel,  nous  avons: 
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60.00  h. 


50.00  h. 


40.00  h. 


30.00  h. 


20.00  h. 


10.00  h. 


¥=  0.8238k -0.2685 
R1  =  0.5554 


0.00  h. 


0.00  h.  5.00  11.  10.00  h.  15.00  11.  20.00  h.  25.00  11.  30.00  h.  35.00  h.  40.00  11.  45.00  h. 


Donc  ce  n'est  pas  convaincant  du  tout  au  vu  du  coefficient  de  corrélation... 

Bref,  pour  en  revenir  à  notre  exemple,  supposons  que  nous  avons  une  tâche  de  3  heures  dont 
nous  souhaiterions  modéliser  la  distribution  statistique  avec  une  fonction  analytique  connue 
(dans  la  pratique  j'utilise  plutôt  la  fonction  de  répartition  empirique  du  postulat  fondamental 
de  la  statistique)  en  nous  basant  sur  l'historique  disponible  dans  le  fichier  MS  Excel.  Dès  lors, 
nous  filtrons  la  table  Excel  afin  de  voir  uniquement  les  tâches  dont  la  durée  initiale  estimée 
est  de  3  heures  (et  nous  faisons  abstraction  du  fait  que  les  départements  nous  sont  connus  afin 
de  simplifier  l'exemple): 
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►  h  Tasks  /  Sheetl  /tl  / 

ce  qui  nous  donne  un  tableau  de  45  lignes.  Maintenant,  dans  MS  Project,  dans  le  ruban 
Add-Ins : 


(Si  id 


File 


Task 


Resource 


Project  -  Microsoft  Project 


Project 


View 


Add-Ins 


Format 


@risk  -  %  fm  g  G  là  2£  1=  "+  m  a.  *♦  ^ 


Menu  Commands 


Custom  Toolbars 


Today 


9:00 


@RISK  ::  Show  Fitting  Window 


Nous  cliquons  sur  le  bouton  @Risk:  Show  Fitting  Window  et  apparaît  alors  la  fenêtre 
suivante: 
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-A  @RISK  for  Project  -  Fitting  i  °  ii 


File  Edit  View  Insert  Simulation  Fitting  Graph  Window  Help 

5» a  l-.b.  a.  f 

aHn  ncs 

J|«  IH  «  =  EHm 

Ready 


dans  la  colonne  Samples,  nous  collons  les  valeurs  résultant  de  notre  filtre  Excel  et  nous 
renommons  la  feuille  @Risk  convenablement  avec  le  nom  3h_Tasks  pour  pouvoir  en  faire 
usage  un  peu  plus  loin: 
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^5  ORISKfor  Project  -  Fittin 
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Maintenant,  afin  d'éviter  d'avoir  trop  de  résultats  (ce  n'est  pas  nécessaire  techniquement 
parlante  mais  c'est  pour  des  raisons  pédagogiques  que  je  fais  la  démarche),  nous  cliquons  sur 
le  bouton  Spectify  Distribution  to  Fit : 


4 

% 

ftj  J>  = 

i  U/r1  1  1 - 

-  Specify  Distributions  to  Fit 

1 

T-nuo— 

? 

1  n  i  n 

Et  nous  cochons  ce  qu'il  faut  pour  dire  que  le  support  de  la  loi  analytique  recherchée  est  semi- 
bornée  [0,+co[  : 
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Specify  Distributions  To  Fit 
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Nous  validons  par  O  K  et  cliquons  sur  le  bouton  Fit  Distribution  to  Input  Data : 
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SLU 


H  fw 


■^^nrinlp-? 


1  Fit  Distributions  to  Input  Data 


Nous  obtenons  alors  avec  le  test  d'ajustement  du  Chi-2: 
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-  @RISK  for  Project  -  Fitting  -  [Fit  Results] 
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Donc  la  meilleure  distribution  avec  ce  test  serait  une  loi  de  Weibull  avec  un  p-value  de  0.1426 
(visible  dans  l'onglet  GOF  se  situant  tout  à  droite).  Nous  allons  d'affichier  les  résultats  dans 
l'ordre  des  meilleurs  résultats  par  rapport  à  d'autres  tests  d'ajustements  en  cliquant  en  bas  à 
droite  dans  l'option  Rank  by. 


2  Invalid  Fits 


Rank  by 

A-D 

1UBSCI . |\ 

A-D  W 

K-S 

Name 

Avec  le  test  d'ajustement  d'Anderson-Darling  (A-D),  le  meilleur  ajustement  serait  une  loi 
InvGauss  mais  la  p-value  est  tellement  petite  qu'il  n'a  pas  pu  la  calculer,  d'où  le  N/A  visible 
dans  l'onglet  GOF : 
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■A  @RISK  for  Project  -  Fitting  -  [Fit  Results] 
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et  pour  le  test  de  Kolmogorov-Smirnov  (K-S),  nous  avons  guère  mieux: 


@RISKfor  Project  -  Fitting  -  [Fit  Results] 

GïS  :ile  Edit  View  Insert  Simulation  Fitting  Graph  Window  Help 
ll»»|a|^Mfi|A.|#P|||Q|Z||l|BB  Density 
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11 
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12 

0.15 

13 
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14 
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15 
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16 

5.50 

17 

0.85 

18 
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19 
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20 
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21 
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22 
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23 
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24 
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25 
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26 
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27 
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28 
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Fitted  Distributions 


T  riang 

Logistic 

BetaGeneral 

LogLogistic 

Weibull 

ExtValue 

Pearson5 

Lognorm 

InvGauss 

Expon 

Uniform 

Pareto 


2  Invalid  Fits 
Rank  by  [K-S 


Comparison  j  Différence  |  P-P  |  Q-Q  | 


Normal(2.2114;  1.6082) 


Ready 


SIHDB 


Stats  GOF  | 

Chi-Sq 

1  A-D  | 

K-S 

Test  Value 

18.55 

1.177 

0.1482 

P  Value 

0.0097 

<  0.005 

0.01  <=  p  <=  0.025 

Rank 

8 

8 

1 

C.Val  @  0.75 

4.2549 

N/A 

N/A 

jjjfC.Val  @  0.5 

6.3458 

N/A 

N/A 

C.Val  @  0.25 

9.0371 

0.4616 

N/A 

C.Val  @0.15 

10.7479 

0.5510 

0.1148 

C.Val  @  0.1 

12.0170 

0.6197 

0.1213 

C.Val  @  0.05 

14.0671 

0.7386 

0.1326 

C.Val  @0.025 

16.0128 

0.8574 

0.1474 

C.Val  @  0.01 

18.4753 

1.0165 

0.1533 

C.Val  @0.005 

20.2777 

1.1383 

N/A 

C.Val  @  0.001 

24.3219 

N/A 

N/A 

#  Bins 

8 

N/A 

N/A 

Bin  #1  Min 

-Infinity 

N/A 

N/A 

Bin  #1  Max 

0.36143 

N/A 

N/A 

Bin  #1  Input 

5 

N/A 

N/A 

Bin  #1  Fit 

5.50 

N/A 

N/A 

Bin  #2  Min 

0.36143 

N/A 

N/A 

Bin  #2  Max 

1.12668 

N/A 

N/A 

Bin  #2  Input 

10 

N/A 

N/A 

Bin  #2  Fit 

5.50 

N/A 

N/A 

Bin  #3  Min 

1.12668 

N/A 

N/A 

Bin  #3  Max 

1.69894 

N/A 

N/A 

Bin  #3  Input 

6 

N/A 

N/A 

Bin  #3  Fit 

5.50 

N/A 

N/A 

Bin  #4  Min 

1.69894 

N/A 

N/A 

Bin  #4  Max 

2.21136 

N/A 

N/A 

Bin  #4  Input 

2 

N/A 

N/A 

Bin  #4  Fit 

5.50 

N/A 

N/A 

Bin  #5  Min 

2  21136 

N/A 

N/A 

Il  s'agit  typiquement  d'une  situation  où  le  management  de  l'entreprise  fait  n'importe  quoi  est 
n'est  donc  pas  sous  contrôle  statistique.  Dans  le  cas  présent  il  faudrait  passer  la  distribution 
empirique  mais  comme  ce  support  n'a  pas  pour  objectif  d'être  un  livre  sur  @Risk,  nous  allons 
prendre  la  distribution  de  Weibull  et  nous  en  contenter  pour  la  suite: 
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Weibullfl. 2427;  2.3414]  Shift=+0. 01 1957 
- ^ 


8HI 

-Infinity 


5  673 


En  faisant  ce  choix,  nous  voyons  que  nous  avons  95%  de  probabilité  cumulée  (19  chances  sur 
20),  que  la  tâche  de  3  heures,  dure  en  réalité  entre  0  et  5.673  heures  (avec  la  distribution 
empirique  on  arrive  à  5.5  heures  pour  information...).  Il  serait  intéressant  de  savoir  avant  de 
voir  comment  affecter  cette  distribution  à  notre  tâche  qu'elle  est  la  probabilité  cumulée  d'être 
au-delà  de  3  jours: 
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Weibull{1 .2427;  2.3414)  Shift=+0.Ü1 1 957 


m 


74.2% 


3.000 


\m 

-i-l  nfi  n  ity 


Donc  1  chance  sur  4....  c'est  mal  barré...  pour  les  tâches  de  3  heures  du  projet  pour  le  moins... 
(bon  pour  les  autres  ce  n'est  pas  mieux  non  plus  pour  information...)  Nous  n'allons  pas  nous 
étendre  sur  le  sujet  des  réserves  mathématiques  pour  gérer  cette  situation  délicate  et  un  peu 
catastrophique.  Ce  qui  nous  intéresse  est  d'appliquer  cette  distribution  à  une  tâche  de  3  heures 
sur  le  planning.  Donc  dans  MS  Project,  nous  retournons  sur  le  Gantt: 


o 

Task  T 
Mode 

Task  Marne  T 

Duration  T 

0 

% 

"  Project 

0.38  clays 

1 

re  1 

1  Cahier  des  charges 

3  hrs 

Nous  cliquons  sur  la  cellule  3  hrs  et  ensuite  cliquons  sur  le  bouton  @Risk:  Define 
distribution : 


n* 


CttlâSE  -+ 


Custom  Tool 


@RISK;  Define  Distribution 


Dans  la  fenêtre  qui  apparaît,  il  suffit  d'ouvrir  la  liste  déroulante  Source  et  de  choisir  Fit 
Results : 
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et  ensuite,  dans  la  liste  Tab,  choisir  le  nom  de  la  feuille  de  Fit  créée  plus  haut: 
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et  de  valider  par  Apply.  Ensuite,  vous  effectuez  la  même  démarche  pour  toutes  les  tâches  du 
projet  +  pour  une  tâche  tampon  située  sur  le  chemin  critique  qui  doit  représenter  les  tâches 
oubliées  dans  les  projets  passés  et  de  la  lancer  la  simulation  sur  une  variable  d'observation 
(bref  y'a  plus  ka  y  faut  kon...). 


Non  plus  sérieusement,  après  cela  devient  un  cours  sur  comment  faire  des  statistiques  et 
cliquer  sur  des  boutons  et  mes  autres  livres  ratissent  déjà  le  sujet  en  long  et  en  large  dans  les 
détails. 


Enfin  pour  clore  signalons  l'indice  appelé  "criticality  index"  assez  utile  dans  la  pratique  et 
recommandé  par  le  PMI  comme  étant  %  de  fois  dans  une  simulation  qu'une  tâche  devient 
critique.  Malheureusement  je  n'ai  jamais  trouvé  de  logiciel  de  simulation  à  ce  jour  qui  affiche 
ce  nombre  (n'hésitez  pas  à  me  contacter  si  vous  en  connaissez). 

8.6.3. 3.6.2.4  Bootstrapping  (approche  simulatoire) 

Nous  allons  illustrer  le  principe  du  bootstrap  (dit  aussi  "bootstrapping")  sur  l'exemple  de 
l'intervalle  de  confiance  de  l'espérance  p  d'une  variable  aléatoire.  Pour  cet  exemple, 
l'intervalle  de  confiance  de  l'espérance  d'une  variable  aléatoire  est  parfaiement  déterminé  à 
partir  de  la  moyenne  et  de  la  variance  calculées  sur  l'échantillon  (voir  mon  livre  sur  les 
mathématiques  appliquées)). 

Nous  considérons  un  échantillon  de  la  variable  aléatoire  composé  de  n  =  10  estimations 
(typiquement  lors  d'un  Scrum  Poker): 

X  ={16,12,14,6,43,7,0,54,25,13} 


La  moyenne  arithmétique  de  l'échantillon  est: 


i  n  i  iu 


Ui= 1 


et  son  écart-type  (estimateur  de  maximum  de  vraisemblance  non  biaisé): 


gu-»)-17-» 

Comme  nous  sommes  dans  la  situation  d'une  variance  empirique  connue  et  d'une  moyenne 
empirique  connue,  pour  faire  le  calcul  d'un  intervalle  de  confiance  nous  avons  alors  démontré 
dans  mon  livre  de  mathématiques  appliquées  qu'il  fallait  utiliser: 

v«  v« 

où  S  est  une  autre  notation  traditionnelle  dans  certains  domaines  de  la  statistique  pour  la 
notation  de  l'écart-type  empirique.  Nous  avons  alors  pour  l'intervalle  de  confiance  à  95%  de 
l'espérance: 
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19- 


17.09 . 

yfïÔ 


^2.5%  (9)  <  //  <  19  + 


17.09, 

VTô 


l2.5 


(9) 


Soit: 


19- 


17.09 

Vïô 


2.26  <  //  <  19  + 


17.09 

Vît) 


2.26 


Ce  qui  donne: 


4.49  <ju<  33.51 

L'intervalle  de  confiance  peut  être  également  calculé  par  bootstrap.  Il  est  alors  obtenu  par 
l'algorithme  suivant: 


A  partir  de  l'échantillons  initial,  nous  simulons  de  nouveaux  échantillons,  appelés  "répliques", 
de  taille  n,  par  tirages  aléatoires  avec  remise.  Par  exemple  avec  la  série  précédente  nous 
pourrions  obtenir  la  réplique  suivante: 

X  *  =  {54, 0, 16, 7, 43, 54, 0, 25, 25, 6} 

dans  laquelle  certaines  valeurs  de  l'échantillons  initiale  ne  figurent  pas,  et  où  d'autres 
apparaissent  plusieurs  fois.  Plusieurs  échantillons  sont  ainsi  simulés.  Nous  pouvons  ainsi 
former  un  nombre  de  répliques  (arrangements)  égal  à  (voir  mon  livre  sur  les  mathématiques 
appliquées): 


Pour  chaque  échantillon  simulé,  une  moyenne  est  calculée  (plusieurs  milliers  de  moyennes!). 
L'intervalle  de  confiance  à  95%  est  défini  sur  cet  ensemble  de  moyennes  typiquement  à  l'aide 
du  calcul  des  centiles  (via  les  fonctions  d'un  tableur  ou  d'un  langage  de  programmation). 

Evidemment  pour  chaque  ensemble  de  plusieurs  milliers  de  valeurs,  les  centiles  ne  seront  pas 
les  mêmes  donc  il  est  même  possible  de  créer  un  intervalle  de  confiance  pour  les  centiles  eux- 
mêmes! 


Il  est  très  facile  (au  même  titre  que  la  méthode  de  Monte-Carlo)  de  créer  des  répliques  avec 
des  tableurs  (de  type  MS  Excel)  sans  faire  de  la  programmation  informatique!  En  plus  la 
technique  du  bootstrap  est  très  puissante  car  elle  ne  fait  appel  à  aucune  hypothèse  sur  la 
distribution  statistique  sous-jacente.  Le  domaine  le  plus  courant  et  simple  d'application  du 
bootstrapping  est  la  gestion  de  projets  où  lors  de  réunions  avec  une  dizaine  de  ressources 
chacun  estime  la  durée  d'une  tâche  ou  d'une  phase. 

Le  bootstrap  peut  donc  être  appliqué  à  tout  estimateur  autre  que  la  moyenne,  tel  que  la 
médiane,  le  coefficient  de  corrélation  entre  deux  variables  aléatoires  ou  la  valeur  propre 
principale  d'une  matrice  de  variance-covariance  (pour  l'analyse  en  composantes  principales)  et 
c'est  là  sa  grande  force!  !  !  Effectivement,  pour  ces  estimateurs,  il  n'existe  pas  de  relation 
mathématique  qui  définisse  l'erreur-standard  ou  l'intervalle  de  confiance.  Les  seuls  méthodes 
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applicables  sont  des  "méthodes  de  ré-échantillonage"  (resampling)  comme  en  fait  partie  le 
bootstrapping. 

8.63.4  Coûts  du  projet 

Bon  il  y  a  beaucoup  de  choses  à  dire  dans  le  domaine  de  l'estimation,  de  la  gestion,  du  suivi  et 
des  calculs  de  coûts  (budgets),  des  provisions  pour  aléas  ou  des  risques,  des  retours  sur 
investissements  et  taux  de  rentabilité.  C'est  un  sujet  vaste  qui  peut  faire  bien  évidemment  sujet 
d'un  livre  de  plusieurs  milliers  de  pages  à  lui  seul.  Par  ailleurs,  je  recommande  la  lecture  du 
chapitre  d'Économie  ainsi  que  sur  les  Techniques  De  Gestion  que  j'ai  écrit  dans  mon  ouvrage 
sur  les  Mathématiques  Appliquées  pour  ceux  qui  souhaiteraient  acquérir  des  connaissances  de 
niveau  maîtrise  universitaire  sur  le  sujet. 

8.63.4. 1  Actifs  financiers 

Il  est  évident  que  pour  des  gros  projets  nécessitant  des  matières  premières  ou  le  travail  dans 
un  environnement  avec  des  multiples  devises  qu'il  faudra  prendre  des  positions  sur  les 
marchés  financiers  en  faisant  l'acquisition  d'options  ou  de  futures  et  en  oubliant  pas  de  faire 
des  contrats  à  taux  de  change  fixe  avec  les  fournisseurs. 

L'ingénierie  financière  étant  un  métier  à  partir  entière  (comme  chacun  des  domaines 
distinctement  définis  par  le  PMBOK),  il  serait  aberrant  que  j'aborde  dans  le  présent  ouvrage  la 
culture  et  les  mathématiques  associées.  Pour  les  détails,  le  lecteur  pourra  encore  une  fois  se 
reporter  à  mon  livre  sur  les  Mathématiques  Appliquées  (section  d'Économie). 

Je  tiens  cependant  à  préciser  pour  ceux  n'ont  jamais  fait  de  gestion  financières  que  l'on 
considère  dans  ce  domaine  l'escalade  de  connaissances  en  complexité  croissante  suivante: 

1.  Finance  comptable  (sommes,  soustractions,  additions,  divisions) 

2.  Finance  actuarielle  (valeurs  immobilisées  actualisées  au  cours  sans  risque) 

3.  Finance  mathématique  (intervention  de  modèles  stochastiques) 

4.  Ingénierie  financière  (succession  de  bricolages  d'ajustements  de  modèles  complexes) 

8.63.4.2  Centre  de  coûts 

Le  centre  de  coûts  est  une  entité  structurelle  d'un  périmètre  analytique  qui  représente  un 
périmètre  clairement  délimité  où  des  coûts  surviennent.  Vous  pouvez  effectuer  des  divisions 
organisationnelles  en  fonction  de  points  de  vue  fonctionnels,  liés  à  l'imputation,  liés  à 
l'activité,  spatiaux  et/ou  liés  aux  responsabilités. 

Dans  un  cahier  des  charges  ou  logiciel  de  gestion  de  projets,  il  est  très  courant  d'avoir  un 
premier  tableau  du  type  suivant  (d'ailleurs  il  serait  bien  qu'il  y  ait  une  norme  internationale 
pour  les  cahiers  des  charges): 


Dépenses  Totales 

Centre  de  coûts  1 

20 

Centre  de  coûts  2 

30 

Centre  de  coûts  3 

40 

Centre  de  coûts  4 

10 

Total  société 

100 
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Et  sinon  un  autre  tableau  très  intéressant  peu  que  l'ensemble  des  logiciels  de  gestion  de  projets 
que  je  connais  n'implémentent  malheureusement  pas  par  défaut: 


Coût  non 
productif 

Coût  de  gestion  des  tâches  courantes 

Coût  p 127524 
rojets 

Total 

Al 

A2 

A3 

PI 

P2 

Centre  de 
coûts  1 

4 

10 

4 

- 

2 

- 

20 

Centre  de 
coûts  2 

7 

5 

10 

- 

3 

5 

30 

Centre  de 
coûts  3 

10 

10 

- 

- 

20 

- 

40 

Centre  de 
coûts  4 

2 

- 

- 

8 

- 

- 

10 

Total 

23 

25 

14 

8 

25 

5 

100 

8.6.3.43  Ratio  Bénéfice  Coût  (RBC) 

Le  RBC  ou  BCR  (Benefit  Cost  Ratio)  est  simplement  un  indicateur  comptable  donné  par  le 
rapport  entre  ce  que  coûtera  ou  a  coûté  un  projet  et  ce  qu'il  devrait  rapporter  ou  a  rapporté. 
Ainsi,  un  projet  estimée  à  1.2M$  qui  devrait  rapporter  1.5M$  le  calcul  donne: 

BCR  =  —  =  1.25 

1.2 


Ainsi,  chaque  1.-  investit  rapportera  1.25.-. 

En  utilisant  cet  indicateur  il  faut  faire  attention  à  l'appréciation  de  la  monnaie  (un  dollar 
aujourd'hui  ne  vaut  pas  un  dollar  dans  un  an!). 

8.63.4.4  Economie  Value  Add  (EVA) 

Imaginons  projet  ayant  nécessité  un  investissement  de  175 '000$  et  que  ce  même  projet  a 
permis  d'obtenir  un  profit  net  de  10'000$. 

Si  nous  considérons  que  le  taux  géométrique  moyen  du  marché  des  actifs  financiers  est  de 
4.5%  alors  nous  avons: 


EVA  =  10 '000  - 175 '000  •  4.5%  =  -2 '125$ 
donc  il  aurait  été  plus  intéressant  d'investir  sur  les  marchés  financiers  à  risque  égal. 

Il  s'agit  évidemment  d'une  approche  comptable. 

8.63.4.5  Return  On  Invested  Capital  (ROIC) 

Imaginons  un  projet  ayant  nécessité  un  investissement  de  175'000$  et  que  ce  même  projet  a 
permis  d'obtenir  un  revenu  de  60'000$  la  première  année,  avec  20'000$  de  coûts  de 
fonctionnement  et  une  taxe  de  8750$.  Nous  aurons  alors: 


ROIC  = 


60'000-40'000-10'000 
175 '000 


ÎO'OOO 
175 '000 


5.7% 
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Ce  qui  signifie  que  le  projet  à  un  rendement  annuel  net  de  -5.7%  sur  l'investissement  effectué. 
Il  s'agit  là  encore  une  fois  d'une  approche  comptable. 

Remarque:  Comme  nous  le  verrons,  contrairement  à  une  idée  très  faussement  répandue,  le 
retour  sur  investissement  réel  n'est  pas  la  simple  différence  entre  l'argent  dépensé  et  l'argent 
gagné.  C'est  un  peu  plus  subtil. . . 

8. 6. 3. 4. 6  Net  Présent  Value  (NPV/VAN)  et  Internai  Rate  of  Return 
(IRR/TRI) 

Les  méthodes  d'évaluation  des  investissements  fondées  sur  le  cash-flow  actualisés  (discounted 
cash  flow)  sont  aujourd'hui  communément  utilisées  dans  beaucoup  d'entreprises  pour  justifier 
des  projets  souvent  au-delà  du  million  de  francs  seulement.  En  s'appuyant  sur  ces  méthodes, 
l'idée  est  de  chercher  à  maximiser  la  valeur  actuelle  nette  VAN  (NPV  en  anglais  en  anglais 
pour  Net  Présent  Value)  et/ou  à  augmenter  le  taux  de  rendement  interne  (IRR).  De  plus,  la 
période  de  remboursement  peut  également  avoir  une  influence.  Par  exemple,  certaines 
entreprises  insisteront  pour  qu'un  projet  ait  un  taux  de  rendement  interne  TRI  (IRR  en  anglais) 
d'au  moins  15%  et  une  durée  de  retour  sur  investissements  de  moins  de  deux  ans.  Le  seuil  de 
l'IRR  est  établi  pour  sélectionner  les  projets  ayant  des  rendements  supérieurs  à  ceux  exigés 
par  le  marché  et  les  besoins  de  l'entreprise.  La  période  de  remboursement  permet  de  contrôler 
les  cash-flows  et  de  s'assurer  que  les  résultats  attends  ne  seront  pas  obtenus  à  trop  long  terme. 
Des  entreprises  différentes  établiront  des  seuils  différents.  Celles  qui  ont  des  cycles  de  vie  de 
produit  très  courts  auront  tendance  à  établir  des  périodes  de  remboursement  courtes  et  des 
objectifs  de  IRR  élevés. 

Il  est  donc  important  dans  le  cadre  de  la  gestion  de  projet  d'effectuer  quelques  calculs  quant 
aux  décisions  à  prendre  relativement  aux  investissements  (même  s'il  communément  connu 
que  la  majorité  des  entreprises  PME/Multinationales  maquillent  leurs  vrais  chiffres). 

8. 6. 3.4. 6.1  NPV /V AN  et  IRR/TRI  en  avenir  certain 


La  valeur  actuelle  nette  VAN  est  la  différence  déterministe  entre  la  valeur  actuelle  des 
dépenses  et  entrées  futures  réactualisées  (il  s'agit  donc  d'une  approche  actuarielle).  Nous 
démontrons  qu'elle  est  donnée  par: 


JL  C  V 

VAN  =  Ÿ - k— - - — — 

(1  +  t%)k  (1  +  t%)k 


'Y  Çk 

ùa +t%f 


■K 


Équation  9  VAN 


où: 


1 .  t%  est  le  taux  moyen  géométrique  sans  risque  du  marché  souvent  pris  sur  la  base  de  la 
courbe  des  taux  zéro  coupon42. 


42  https://www.llovds.com/the-market/operating-at-llovds/solvencv-ii/information-for-managing- 

agents/guidance-and-workshops/technical-provisions-and-standard-formula  ou  pour  la  Suisse 
http://www.snb.ch/en/iabout/stat/statpub/statmon/stats/statmon/statmon  E4  ou  encore  http://www.six-swiss- 
exchange.com/services/vield  curves  en.html 
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Pour  indication  voici  quelques  performances  financières  (soit  disant)  de  l'année  en 
cours  des  Hedge  Fund  du  Crédit  Suisse  http://www.hedgeindex.com  ou  de  ces 
dernières  années  de  la  société  Vanguard®  sur  des  investissements  autres  que  des 


vanguard/investment-Dri  ncioles)  : 

2004 

2805 

2086 

2087 

15.81* 

55.84% 

2288% 

28.64% 

Hm 

3578% 

6.77% 

14.48% 

34.51% 

2.43% 

163%  4444% 


Actions  a  laibio  copiai' nation 


Actions  de  croissance 


55  98* , 


Actions  smorgoatos 


OfciipittoiK  eutopeem 


Actions  a  moyenne  capitalisation 


Actions  à  forte  capitalisation 


I  LéMLMMlÉaiUaoieiUÉiyH 


Figure  35  Rendements  d'actifs 


2. 


Les 


Ct 


(l +t%)k 

un  temps  k. 


donnent  le  capital  initial  investi  pour  arriver  à  chaque  capital  Ck  après 


n  c 

3.  La  somme  V - - — -  donne  donc  le  capital  total  à  investir  pour  arriver  au  capital 

S(i  +  t%Ÿ 

récupéré  des  Ck  après  leur  temps  respectif  d'investissement  k. 


4.  Le  terme  ^ - - — -  donne  le  capital  initial  à  investir  pour  arriver  après  n  périodes 

k= î  (1  + 1%) 

au  capital  versé  Vk  après  leur  temps  respectif  d'investissement  k.  Nous  avons  V0  qui 
est  le  premier  investissement  de  départ. 

En  fin  de  compte,  la  somme: 


y  Çk  Yh 

ùa+t%Ÿ 
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Classe  d'actifs  la  plus  performante  Classe  d'actifs  la  moins  performante 


donne  le  capital  total  à  placer  en  épargne  pour  arriver  aux  sommes  respectives  des  Vk ,  Ck 
après  leurs  périodes  d'investissement  respectives. 

Donc  la  différence: 


«  C  —  V 

VAN  =  V — - - k--V0 

fera +t%)k 

nous  informe  si  les  investissement  Vi  sont  plus  intéressants  que  la  stratégie  consistant  à 
épargner  pendant  des  périodes  respectives  des  sommes  qui  nous  auraient  permis  d'arriver  aux 

ck. 

Le  taux  de  rentabilité  interne  TRI  est  le  taux  d'actualisation  pour  lequel  la  VAN  du  projet  est 
nulle.  Il  s'agit  en  fait  de  trouver  le  taux  t%  tel  que: 


VAN  = 


Cy 


■  +  ■ 


a 


i +t%  a +t%y 


■+...+■ 


c 


(i +t%y 


-K 


Vy 


V. 


1  +  t% 


(i +t%y 


Cr-v, ,  ç-v. 


■  + 


î +t%  a +t%y 


■+...+ 


Ci  zXa 

a +t%y 


■v0=o 


Il  existe  une  fonction  spéciale  pour  cela  dans  MS  Excel,  la  fonction  TRI  mais  qui  ne  gère  que 
le  cas  particulier 


=  TRI(V0,Cl  —  V1  ;C2  -V2;...;Cn  -  V/, [estimation]) 

Voyons  quelques  exemples  par  la  pratique  sur  les  concepts  majeurs  que  sont  la  Net  Présent 
Value  et  le  Internai  Rate  of  Return 

Remarque:  Les  définitions,  explications,  détails  et  démonstrations  mathématiques  de  ces 
concepts  sont  disponibles  sur  www.sciences.ch. 

Exemple: 

Un  ami  vous  propose  d'investir  2'000.-  dans  un  projet  ayant  un  cash-flow  qui  double  chaque 
période  sur  une  base  de  400.-  assurée  pendant  3  périodes  alors  que  le  taux  moyen  géométrique 
d'intérêt  du  marché  est  de  5%.  L'investissement  est-il  intéressant? 

Pour  répondre  à  cette  question  nous  savons  donc  que  nous  aurons  pour  les  3  périodes 
respectivement  400.-,  800.-  et  1600.-  de  cash-flow 

Pour  obtenir  chacune  de  ces  trois  sommes  à  5%  pendant  1,  2  et  3  périodes  respectives  nous 
aurions  dû  épargner  une  somme  initiale  de: 

^  Ck  400  800  1600  _,,00„ 

\  _ k  — _ | _ | _ _  2  488  72  _ 

tl(\+t%)k  (1  +  5  %Ÿ  (l  +  5%)2  (l  +  5%)3 

La  somme  à  capitaliser  est  donc  plus  grande  que  la  somme  de  2'000  à  investir  que  nous 
propose  notre  ami.  La  VAN  est  donc  positive  et  égale  à: 
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VAN  =  2'488.72-2'000  =  488.72 


Pour  obtenir  ce  résultat  sous  MS  Excel  il  suffit  d'écrire: 


=-2000+V  AN  (5  %  ;400;800;  1 600)=2'488 .72.- 

Le  projet  est  donc  intéressant  car  la  différence  est  positive  (le  VAN  est  de  +488.72.-)!  Il  est 
aussi  pertinent  de  faire  remarquer  par  cet  exemple  que  la  VAN  n'est  pas  simplement  égal  au 
Retour  Sur  Investissement  (R.O.I)  ...  : 

(400+800+ 1 600)-2000=800.- 

Pour  le  calcul  du  TRI  il  nous  suffit  de  poser: 


400 

(i  +  t%Ÿ 


800 

(1  +  t%)2 


1600 
(i +t%)3 


-2000  =  0 


et  de  trouver  le  bon  t%.  Pour  cela  nous  allons  recourir  au  logiciel  standard  MS  Excel  en 
écrivant  (attention  à  mettre  V0  toujours  en  premier  et  ensuite  à  l'ordre  chronologique  des  cash- 
flows!)  la  formule: 


=TRI(  { -2000;400;800;  1 600  })=  15. 1 1 7% 

Vous  pourrez  toujours  essayer  de  trouver  un  tel  taux  d'intérêt  sur  le  marché. . . 

Il  est  clair  que  si  le  TRI  est  négatif  (donc  la  VAN  aussi),  il  ne  vaut  même  pas  la  peine  de 
penser  à  investir  dans  le  projet.  Mieux  vaut  aller  voir  une  banque. 

Par  ailleurs,  au-delà  d'une  certaine  valeur  négative,  MS  Excel  renvoie  #NOMBRE.  Il  faut 
alors  passer  par  des  logiciels  un  peu  plus  puissants  (comme  Maple  par  exemple) 


8. 6. 3.4. 6. 2  Net  Future  Value  (NFV)  en  avenir  certain 

Nous  venons  de  voir  plus  haut  que  la  relation: 

k  C  —  V 

VAN  =  V — - - k--V0 

tra +t%f 


Permettait  donc  de  savoir  le  montant  en  numéraires  qui  investit  aux  taux  de  rendement 
géométrique  moyen  du  marché  donne  donc  le  même  résultat  que  les  cash-flows  du  projet 
pendant  la  même  période  de  temps. 

Cependant  un  autre  point  de  vue  qui  est  parfois  intéressant  revient  à  savoir  le  montant  que 
nous  auraient  rapporté  les  investissements  des  cash-flows  investis  (valeur  nette  future): 

nfv  =  -v0  a + t%y  +  £  (ck  -  vk  )(i + t%y~k  =  van  •  (1 + t%)n 

k=l 

Par  exemple  si  nous  considérons  un  projet  d'un  investissement  initial  de  2'000.-  (équivalent  à 
un  débit  bancaire  négatif)  et  de  cash-flow  positifs  de  respectivement  400.-,  800.-  et  1  '600.- 
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(équivalent  à  faire  un  crédit  bancaire  à  chaque  période  respective),  le  montant  final  si  le  taux 
géométrique  moyen  du  marché  est  de  5%  alors  de: 

NFV  =  -2000(1  +  5 %f  +  400(1  +  5%f  +  800(1  +  5%)  + 1600  =  565.75.  - 

Ce  qui  équivaut  donc  au  montant  obtenu  en  considérant  les  cash-flows  positifs  ou  négatifs 
directement  posés  sur  un  compte  bancaire. 

8. 6. 3.4. 6. 3  NPV/VAN  et  IRR/TRI  en  avenir  incertain  par  scénarios 

Les  calculs  précédemment  présentés  du  VAN  (NPV)  sont  considérés  comme  naïfs. 
Effectivement,  la  prise  en  considération  du  facteur  risque  exige  dans  le  cadre  d'évaluation  des 
projets  d'investissement  l'utilisation  des  outils  statistiques  appropriés  tels  que  l'espérance 
mathématique,  l'écart-type  voir  même  parfois  la  loi  Beta. 

Lorsque  les  valeurs  possibles  du  cash-flow  ou  de  la  valeur  actuelle  nette  ne  permettent  pas  de 
sélectionner  des  projets  en  compétition,  nous  utilisons  la  dispersion  statistique  de  ces 
différentes  valeurs. 

La  mesure  de  cette  dispersion  se  fait  par  le  calcul  de  la  variance  de  la  variable  aléatoire 
concernée.  Il  s'agit  alors  de  chercher  à  maximiser  l'espérance  mathématique  (la  moyenne)  de 
la  VAN  notée  E(VAN)  et  à  minimiser  la  variance  (ou  in  extenso  l'écart-type)  de  la  VAN 
notée  V (VAN)  (ou  u(VAN )  pour  l'estimateur  de  maximum  de  vraisemblance  du  VAN). 

Avant  de  voir  quelques  exemples  d'application,  rappelons  quelques  propriétés  élémentaires  de 
l'espérance  et  de  la  variance: 


E(aXl  +bX2)  =  aE(Xl  )  +  bE(  X2  ) 


Équation  10  Linéarité  espérance 

L'espérance  mathématique  du  VAN  peut  alors  se  calculer  aisément  à  partir  de  la  relation 
suivante: 


E(VAN )  =  £ 


E(Ck) 


e  <yk) 


k-y0 


(i + t%y  (î + 1%) 

Idem  pour  la  variance  où  nous  démontrons  que: 

V(aX1  +bX2)  =  a2E(Xl  )  +  b2E(X2) 

si  et  seulement  si  les  deux  variables  ont  indépendantes  (covariance  nulle). 
Alors: 


V(VAN)  = 


éra +t%)k 


tout  en  se  rappelant  que: 
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V(x)  =  YJPiXf-E(X)2 


Vincent  ISOZ 


Equation  11  Formule  de  Huyghens 


Remarques: 

RI.  Nous  avons  E(C )  =  C  puisque  celle-ci  est  une  valeur  certaine! 

R2.  Nous  avons  V(V0)  =  V(C)  =  0  puisque  V0,C  sont  des  valeurs  certaines. 

Exemple: 

Soit  un  projet  dont  les  cash-flows  annuels  possibles  sont  estimés  comme  suit  (chiffres  en  kilo 
francs): 

•  Année  1:  20,  40,  60,  80 

•  Année  2:  40,  60,  70,  90 

•  Année  3:  30,  40,  60,  80 

Avec  des  possibilités  respectives  de  =  20%,  P2  =  30%,  P,  =  30%,  P4  =  20%  . 

Sachant  que  le  montant  de  l'investissement  est  de  100'000.-  et  que  le  taux  moyen  géométrique 
du  marché  est  de  12%.  Calculer  l'espérance  de  ce  projet  et  la  variance  de  ce  projet. 

Solution: 

L'espérance  du  VAN  est  donnée  par: 


_  (20  •  0,2  +  40  •  0.3  +  60  •  03  +  80  •  0.2)  (40 -0,2 +  60-0.3 +  70-03 +  90-0.2) 

(1  +  12%)*  (1  +  12%)2 

(30  •  0.2  +  40  •  0.3  +  60  •  03  +  80  •  0.2) 

+  - - - - --100 

(1  +  12%)3 

=  50  •  0.893  +  65  •  0.797  +  52  •  0.712  - 100  =  33.479.  -  kF 


La  variance  par: 
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VtVAN,  =  f 


V(Ct) ^JJPiC;-E(CiŸ 


k= 1 


(i  +  t%y 


=z 


k= 1 


(i +t%y 


202  •  0.2  +  402  •  0.3  +  602  •  0.3  +  802  •  0.2  -  502 


a+12%)1 

402 

•0.2  +  602 

•0.3  +  702  -  0.3  +  902 

•0.20- 

-652 

(1  + 12%)2 

302 

•0.2  +  402 

•0.3  +  602  -  0.3  +  802 

•0.20- 

-502 

(1  +  12%)3 

_  2920  -  502  4490  -  602  3020  -  522  _  480  265  316 

_  a  +  12%)1  (1  + 12%)2  (1  +  12%)3  _(1  +  12%)1  (1  +  12%)2  (1  +  t%Ÿ 

=  428.64  +  21 1.205  +  224.992  =  864.837 kF 


et  donc: 


a  =  V864.837  =  29.40 kF 

Entre  deux  ou  plusieurs  projets  concurrents,  nous  retenons  celui  dont  l'espérance 
mathématique  de  la  VAN  est  la  plus  élevée  et  l'écart-type  de  la  VAN  la  plus  faible. 

8. 6. 3.4. 6.4  NPV/VAN  par  processus  binomial 

Les  techniques  que  nous  avons  vu  précédemment  ne  prennent  pas  en  compte  qu'à  chaque 
étape  d'un  projet,  celui-ci  peut  échouer  ou  être  abandonné  (les  exemples  de  ce  type  sont 
légions  dans  les  médias  où  des  grands  projets  gouvernementaux  sont  cités).  Donc  le  modèle 
en  avenir  incertain  est  lui-même  aussi  naïf  car  il  considère  que  nous  arrivons  jusqu'au  bout  du 
projet  avec  une  probabilité  de  100%. 

Dans  la  pratique,  il  faut  évaluer  les  probabilités  de  chaque  jalon  du  projet.  Ces  probabilités 
sont  évidemment  fixées  sur  la  base  du  REX  (retour  sur  expérience)  du  responsable  de  projet. 

Le  lecteur  devinera  probablement  tout  de  suite  que  prendre  en  compte  les  probabilités 
d'échecs  ou  de  réussite  a  pour  effet  de  diminuer,  souvent  drastiquement,  le  VAN  calculé  avec 
les  méthodes  naïves  (même  le  VAN  avec  les  scénarios  est  diminué  souvent  drastiquement!). 

Par  exemple,  considérons  l'arbre  binomial  suivant  (source:  Projet  de  Migration  IT  SwissRe, 
Thèse  de  Mater  ETHZ  de  Thomas  Ukelo  Mbolo): 
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Phase  I  __  _  Phase  E  _  __  Phase  ni  __  _  Phase  IV 

"*  WV7  2ÔÔS  M  Ü55  2ÔÏÔ  *" 

Nous  considérons  que  la  probabilité  de  réussite  de  la  phase  II  est  de  30%,  celle  de  la  de  phase 
III  de  90%,  celle  de  la  troisième  phase  IV  de  95%. 

8.6.3A7  fV @R  et  tV@R 

La  VAN,  eVAN  et  IRR  sont  des  outils  utilisés  depuis  maintenant  plus  de  un  siècle  dans  la 
gestion  de  projets.  Outre  le  fait  qu'aujourd'hui  ils  soient  calculés  avec  des  méthodes 
probabilistes  basées  sur  des  simulations  de  Monte-Carlo  ou  non,  il  n'y  a  pas  de  nouveautés 
majeures  relatives  à  ces  trois  indicateurs  d’investissement. 

Ce  qui  est  beaucoup  plus  intéressant  aujourd'hui  est  l'utilisation  de  la  fV@R  (financial  Value 
At  Risk)  -  pendant  financier  du  tV @R  (time  Value  At  Risk)  -  qui  permet  de  connaître  la 
trésorerie  ou  la  réserve  de  temps  à  avoir  pour  couvrir  une  partie  définie  du  risque  si  le  projet  a 
ses  délais  ou  son  budget  qui  suit  une  loi  Normale  (il  faut  donc  absolument  faire  un  test 
statistique  d'ajustement  avant  d'appliquer  cet  outil). 

Cette  technique  de  mathématique  financière  de  couverture  du  risque  m'a  été  inspirée  du 
domaine  des  assurances  (que  le  domaine  bancaire  a  repris  dans  les  années  1980  aux  États- 
unis).  Elle  correspond,  pour  son  pendant  financier,  au  montant  de  pertes  qui  ne  devrait  être 
dépassé  qu'avec  une  probabilité  donnée  sur  un  horizon  temporel  donné.  Ainsi  il  est  possible: 

-  De  parer  avec  un  certain  niveau  de  probabilité  aux  imprévus  financiers  et  temporels 
planifiés 

De  parer  avec  un  certain  niveau  de  probabilité  aux  imprévus  financiers  et  temporels 
non  planifiés 

Cette  approche  est  pratique  car  elle  nécessite  uniquement  de  connaître  deux  chose: 

1.  La  volatilité  générale  du  projet  (ce  qui  normalement  n'est  pas  une  difficulté  majeure) 

2.  De  vérifier  l'hypothèse  de  normalité  de  la  distribution  des  délais  du  projet. 
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J'ai  appliqué  cet  outil  personnellement  pour  la  première  fois  en  2009  dans  des  contextes  réels 
de  projets  et  les  résultats  sont  d'une  redoutable  efficacité!  !  À  ma  connaissance  c'est  la 
première  fois  que  cela  était  utilisé  dans  le  monde  de  la  gestion  de  projets. 

Voyons  un  exemple  du  point  de  vue  financier  (la  démarche  et  les  hypothèses  sont  les  mêmes 
pour  ce  qui  concerne  l'aspect  temporel): 

Un  projet  à  un  coût  espéré  de  ~78'000.-  (espérance)  avec  un  écart-type  (volatilité)  de  3'900.- 
qui  suit  raisonnablement  avec  un  niveau  de  risque  alpha  de  5%  une  loi  Normale  (non  rejet  de 
l'hypothèse  nulle). 

Nous  souhaiterions  déterminer  quelle  est  la  fV@R  que  doit  posséder  le  mandataire  pour 
couvrir  le  risque  de  déviation  de  son  projet  avec  un  intervalle  de  confiance  de  95 %? 

La  réponse  sera  donnée  en  utilisant  la  relation  suivante  dans  MS  Excel: 

=NORMSINV(95%)*3900.-=6'400 

Il  faut  donc  un  capital  risque  de  6'400.-  pour  couvrir  les  pertes  à  95%  pour  ce  projet.  En 
d'autres  termes,  nous  avons  ainsi  5%  de  probabilité  cumulée  (1  chance  sur  20)  de  perdre  plus 
que  6'400.-  et  95%  de  perdre  moins! 

Attention  il  s'agit  d'une  somme  d'argent  (ou  de  temps)  qu'il  s'agit  d'ajouter  à  l'espérance  est  ce 
modèle  n'est  applicable  dans  la  pratique  que  si  l'ensemble  du  projet  suit  une  loi  normale  (ou 
quelque  chose  qui  en  est  suffisamment  proche). 

Remarque:  On  peut  appeler  le  résultat  du  calcul  de  différentes  façons  "réserve  fractionnaire" 
(bien  que  cela  n'ait  aucun  rapport  avec  la  façon  dont  les  Etats  imposent  une  réserve 
fractionnaire  aux  banques)  ou  encore  "réserve  mathématique"  (bien  que  cela  n'ait  aucun 
rapport  avec  la  manière  dont  les  assurances  calculent  la  réserve  mathématique). 

8.6.3A8  Méthodes  d'appréciations  (décisionnelles)  en  avenir  incertain 

Dans  un  tel  cadre,  on  se  trouve  confronté  à  des  problèmes  assez  similaires  à  ceux  associés  à 
ce  qu'on  appelle  la  théorie  des  jeux.  Chaque  choix  du  décisionnaire  peut  en  effet  être 
considérée  comme  une  stratégie  et  la  valeur  du  gain  qu'il  sera  en  mesure  d'en  tirer  dépendra  de 
l'état  futur  qui  lui  est  inconnu...  On  envisage  la  nature  comme  le  second  joueur  et  les  états 
futurs  comme  les  stratégies  de  ce  second  joueur.  Le  décisionnaire  a  alors  la  possibilité 
d'utiliser,  s'il  le  juge  utile,  l'un  des  critères  de  décision  habituels  de  la  théorie  des  jeux.  C'est 
au  travers  de  l'analyse  d'un  exemple  chiffré  que  nous  effectuerons  une  application  de  ces 
divers  critères43 


43  La  théorie  mathématique  sort  du  cadre  de  ce  cours  mais  est  disponible  dans  les  références  bibliographiques  du 
présent  ouvrage 
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PROBABILITES  CONNUES  ? 


Méthode  des  scénarios 
(Opt,  Att,  Pess) 


Théorie  des  Jeux 


— (! 

Théorie  de 

la  décision 

Simulations 

stochastiques 


Analyse  Multicritères 

(matrices  de  décision) 

Arbres  de  Markov 

Un  très  grand  nombre  de  critères  de  décision  ayant  été  développés  au  cours  du  siècle  nous 
nous  limiterons  ici  à  la  présentation  et  à  l'évaluation  des  critères  les  plus  significatifs,  les 
critères  de  Laplace,  de  Wald,  de  Savage  et  Hurwitz  chacun  d'eux  correspondant  à  un  type  de 
comportement  particulier  des  dirigeant  d'entreprises44. 

8. 6. 3.4. 8.1  Le  critère  de  Laplace-Bayes 

Ce  critère  de  Laplace-Bayes  consiste  à  effectuer  une  simple  moyenne  arithmétique  des  gains 
espérés  (ce  qui  revient  à  calculer  l'espérance  en  équiprobabilité),  associés  pour  chaque 
stratégie  aux  divers  états  de  la  nature  puis  à  retenir  la  stratégie  dont  la  moyenne  est  la  plus 
élevée. 

L'avantage  de  ce  premier  critère  réside  dans  sa  simplicité  de  calcul,  son  inconvénient  majeur 
est  d'être  peu  réaliste:  on  prétend  raisonner  en  avenir  indéterminé,  c'est-à-dire  dans  le  cadre 
d'une  situation  où  l'on  ne  peut  pas,  ou  l'on  ne  veut  pas,  affecter  une  probabilité  de  réalisation  à 
chacun  des  états  de  la  nature,  alors  que  le  choix  du  critère  même  équivaut  à  leur  donner  une 
équiprobabilité.  En  outre,  il  correspond  à  un  type  de  comportement  des  dirigeants 
d'entreprises  tout  à  fait  particulier,  caractérisé  par  une  neutralité  à  l'égard  du  risque. 

8. 6. 3.4. 8. 2  Le  critère  de  Wald 

L'adoption  de  ce  critère  correspond  à  une  attitude  prudente  du  preneur  de  décision:  celui-ci 
chercher  à  identifier  pour  chaque  stratégie  possible  l'état  de  nature  qui  conduirait  aux  moins 
bons  résultats.  Après  quoi,  il  cherchera  à  se  couvrir  en  adoptant  la  stratégie  qui  est  susceptible 
de  lui  fournir,  si  l'évolution  de  la  concurrence  s'avère  défavorable  à  l'entreprise,  le  résultat  le 
moins  mauvais  possible  (le  Maximum  des  Minimum  potentiels). 

Il  consiste  à: 


44  Le  lecteur  intéressé  par  un  complément  d'information  pourra  toujours  se  reporter  à  la  documentation 
référencée  à  ce  sujet  sur  le  site  de  sciences.ch 
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-  pour  chaque  décision  (ou  stratégie),  de  retenir  le  résultat  le  plus  faible 

-  parmi  les  moins  bons  résultats,  choisir  le  plus  élevé  des  moins  bons  résultats  des  différentes 
stratégies. 

8.6.3.4.83  Le  critère  du  Maximax 

Selon  la  même  logique  que  le  critère  précédent,  il  s'agit  ici  de  retenir  le  meilleur  des  résultats 
des  différentes  stratégies  possibles.  C'est  un  critère  optimiste  qui  laisse  penser  que  la  nature 
(l'environnement)  est  toujours  favorable  au  décideur. 

Il  consiste  à: 

-  retenir,  pour  chaque  décision  (ou  stratégie)  et  en  fonction  de  chaque  état  la  nature,  le  résultat 
attendu  le  plus  élevé 

-  puis  parmi  ces  résultats,  retenir  la  décision  qui  donne  le  résultat  le  plus  important  parmi  ces 
meilleurs  résultats 

8.63.4.8.4  Le  critère  de  Savage  ou  du  Minimax  Regret 

Comme  le  critère  de  Wald,  le  critère  de  Savage  traduit  une  attitude  de  prudence  de  la  part  du 
décisionnaire:  la  méthode  consiste  à  identifier  pour  chacun  des  états  de  nature  la  stratégie  la 
plus  favorable,  puis  à  évaluer  le  manque  à  gagner  (regret)  que  représenterait,  par  rapport  à 
cette  stratégie  l'adoption  de  chacune  des  autres  stratégies,  enfin  à  retenir  la  stratégie 
conduisant  au  plus  petit  des  regrets  maximum. 

Afin  de  mettre  en  œuvre  ce  critère,  il  convient: 

-  de  déterminer  les  regrets  (ou  manque  à  gagner)  pour  chaque  décision:  on  établit  ainsi  la 
matrice  des  regrets 

-  pour  chaque  décision,  retenir  le  regret  le  plus  élevé 

-  et  enfin,  retenir  la  décision  pour  laquelle  le  regret  maximum  est  le  plus  faible. 

8.63.4.8.5  Le  critère  d'Hurwitz 

Les  deux  critères  précédents  ont  un  caractère  commun:  celui  d'être  associé  à  l'idée  que  la 
nature  est  fondamentalement  hostile  au  joueur.  C'est  cette  idée  que  le  critère  d'Hurwitz  remet 
en  cause,  en  introduisant  la  possibilité  d'une  nature  plus  clémente  à  l'égard  du  joueur. 
Concrètement,  ce  critère  consiste  à  calculer  pour  chacune  des  stratégies  l'espérance  du  pire  et 
du  meilleur  de  ses  résultats  potentiels,  et  à  choisir  la  stratégie  pour  laquelle  celle-ci  est  la  plus 
grand: 


E  =  (l-  p)m  +  pM 


avec  m  le  pire  des  gains,  M  le  meilleur  des  gains,  p  la  probabilité  de  balance  de  décision  du 
décideur. 

Lorsque  p  est  nul,  le  critère  de  Hurwitz  se  confond  avec  le  critère  de  Wald  sinon  si  p  est  égal  à 
l'unité  nous  retombons  sur  le  critère  du  Maximax. 
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Remarque:  nous  avons  ici  délibérément  simplifié  le  modèle  d'Hurwitz  dans  le  cadre  ou 
l'environnement  (la  nature)  n'est  pas  probabiliste  aussi. 

Exercice  (repris  du  l'ouvrage  de  F.  Hémici  et  M.  Bounab): 


Une  entreprise  envisage  les  trois  projets  suivants  Pu  P 2,  P 3  avec  leurs  gains  respectifs. 


État  de  la  nature 

Projet  Pi 
Projet  P 2 
Projet  P 3 


Défavorable  Favorable  Très  favorable 
l'200  l'500  l'800 

700  900  l'200 

-500  l'200  l'600 


Nous  remarquons  tout  de  suite  qu'il  s'agit  ici  d'un  jeu  unilatéral.  Il  n'y  donc  pas  de 
confrontation  avec  un  autre  décisionnaire  comme  c'est  le  plus  souvent  le  cas  en  théorie  de  la 
décision. 


Il  est  demandé  de  classer  les  projets  en  fonction  des  critères  suivants: 

1.  Critère  du  Maximin  (ou  de  Wald) 

2.  Critère  du  Maximax 

3.  Critère  de  Hurwitz 

4.  Critère  de  Laplace 

5.  Critère  de  Savage  (ou  du  Minimax  regret) 

Solutions: 

1.  Pour  appliquer  le  critère  de  Wald  il  faut  dans  un  premier  temps  déterminer  pour  le 
décisionnaire  le  gain  (utilité)  minimum  de  chacune  des  stratégies: 

Pour  le  projet  Pû  Min{  l'200,  l'500,l'800}=l'200 

Pour  le  proj et  P 2 :  Min {700,900,1'200}=700 

Pour  le  projet  P3 :  Min{-500,  l'200,l'600}=-500 

Selon  ce  critère,  c'est  le  projet  1  qu'il  convient  de  retenir,  en  effet,  parmi  les  résultats  les  plus 
faibles  des  trois  projets,  c'est  celui  qui  correspond  au  plus  élevé. 

2.  Pour  applique  le  critère  du  Maximax  il  suffit  de  retenir  le  plus  élevé  de  chaque  projet  en 
fonction  des  différents  états  de  la  nature,  soit: 

Pour  le  projet  Pf.  Min{  l'200,  l'500,l'800}=l'800 

Pour  le  proj  et  P 2  :  Min  {700,  900,  l'200}=l  '200 

Pour  le  projet  P3 :  Min{-500,  l'200,r600}=l’600 

Le  maximum  des  maximums  étant  l'800  c'est  à  nouveau  le  projet  1  qui  est  retenu. 
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3.  Pour  appliquer  le  critère  de  Hurwitz  (dans  sa  version  simple)  on  choisit  (on  peut  démontrer 
d'où  vient  cette  valeur  mais  cela  sort  du  cadre  ce  cours)  p= 0.7  et  la  théorie  de  base  nous 
impose  d'utiliser  que  deux  issues.  Nous  prendrons  alors  seulement  les  optimistes  et 
pessimistes: 


État  de  la  nature 

Défavorable 

Très  favorable 

Projet  P j 

l'200 

l'800 

Projet  P2 

700 

l'200 

Projet  P 3 

-500 

l'600 

L'espérance  de  gain  est  alors: 

Pour  le  projet  P7:  1 '800  •  0.7  + 1 ' 200(1  -  0.7)  =  1 ' 620 

Pour  le  projet  P2 :  l'200  •  0.7  +  700(1  -  0.7)  =  l'050 

Pour  le  projet  P?:  l'600  •  0.7  -  500(1  -  0.7)  =  970 

Ainsi  avec  ce  critère  c'est  le  projet  1  à  nouveau  qu'il  convient  de  choisir. 

Remarque:  cette  méthode  est  à  prendre  avec  des  pincettes  si  non  appliquée  avec  un  spécialiste 
qui  connaît  les  outils  mathématiques  qui  se  cachent  derrière 

4.  Pour  appliquer  le  critère  de  Laplace,  il  suffit  d'appliquer  donc  une  à  chaque  stratégie  de 
projet.  Ainsi: 


Pour  le  projet  P7:  E(P[  )  =  il'200  +  ^l'500  +  ^l'800  =  l'500 


Pour  le  projet  P2 :  P(P2 )  =  ^700  +  ^900  +  ^1200  =  933.34 


Pour  le  projet  P3 :  P(P3)  =  -  ^500  +  ^1200  +  ^1600  =  766.67 


Ainsi  avec  ce  critère  c'est  le  projet  1  à  nouveau  qu'il  convient  de  choisir. 

5.  Pour  applique  le  critère  de  Savage  il  faut  d'abord  créer  la  matrice  des  regrets. 

Si  l'état  de  la  nature  est  défavorable,  le  résultat  le  plus  élevé  est  de  l'200,  nous  allons  alors 
tout  reporter  à  cette  valeur  numérique  et  faire  les  différences  arithmétiques  avec  les  autres 
gains  de  la  même  colonne,  et  de  même  pour  chaque  autre  colonne  avec  l'500  et  l'800. 


Etat  de  la  nature 

Défavorable 

Favorable 

Très  favorable 

Projet  Pi 

0 

0 

0 

Projet  P2 

500 

600 

600 

Projet  P 3 

1700 

300 

200 

Nous  avons  alors: 

Regret  maximum  pour  le  projet  P;:  0 
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Regret  maximum  pour  le  projet  P 2'.  600 
Regret  maximum  pour  le  proj  et  P 3 :  1700 

Il  convient  enfin  de  choisir  le  projet  qui  présente  le  regret  le  moins  élevé,  donc  dans  cet 
exemple  simple,  c'est  à  nouveau  le  projet  1. 

Pour  conclure,  il  convient  de  rappeler  qu'une  décision  d'investissement  est  une  opération 
complexe  qui  fait  intervenir  plusieurs  variables  tant  quantitatives  que  qualitatives  et  qu'elle  ne 
peut  s'appuyer  que  sur  un  seul  critère  ou  même  sur  cinq! 

8. 6. 3.4. 8. 6  Analyses  par  arbres  d'événements  (AAE) 

Le  cas  de  décision  le  plus  simple  dans  l'industrie  l'analyse  par  arbre  d'événement  qui  fait  appel 
(lorsque  les  probabilités  sont  fixes)  aux  axiomes  de  base  des  probabilités  uniquement.  Si  les 
probabilités  ne  sont  pas  fixes  (ce  qui  est  fréquent  dans  la  réalité),  il  faudra  faire  appel  à  des 
logiciels  intégrant  les  méthodes  de  Monte-Carlo  (voir  le  chapitre  à  ce  sujet). 

L'analyse  par  arbre  d'événements  est  une  technique  graphique  permettant  de  représenter  les 
séquences  d'événements  mutuellement  exclusifs  suivant  un  événement  initiateur  en  fonction 
du  fonctionnement/non  fonctionnement  de  divers  systèmes  conçus  pour  limiter  ses 
conséquences  (elle  fait  partie  intégrante  de  la  norme  ISO  31010). 

Voici  un  exemple  simple  effectué  et  automatisé  au  niveau  des  calculs  avec  le  logiciel 
bureautique  Microsoft  Office  Visio  (nous  allons  voir  en  classe  comment  procéder): 


La  fréquence  annuelle  dans  la  colonne  se  trouvant  à  l'extrême  droite  du  tableau  (les  feuilles) 
est  simplement  égale  à  l'estimation  de  la  fréquence  annuelle  de  l'événement  initiateur 
multiplié  par  le  produit  des  probabilités  d'une  branche  tel  que: 
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et  il  faut  bien  évidemment  faire  attention  à  ce  que  la  somme  des  probabilités  dans  chaque 
branche  soit  égale  à  100%. 

8. 6. 3.4. 8.7  Analyses  par  arbres  de  décision  (ADE) 

Les  arbres  de  décision  constituent  un  outil  complémentaire  pour  schématiser  une  décision 
dans  un  univers  incertain  et  dont  la  structure  n'est  pas  adéquate  pour  être  mise  sous  forme  de 
tableau. 

Il  s'agit  donc  encore  une  fois  d'une  technique  très  utile  (elle  fait  partie  intégrante  de  la  norme 
ISO  31010)  pour  clarifier  et  donner  une  ligne  directrice  une  situation  comportant  un  choix 
stratégique.  Il  s'agit  d'une  technique  souvent  utilisée  pour  définir  stratégiquement,  dans  un 
avenir  incertain,  quels  sont  les  projets  qui  ont  l'espérance  de  gain  la  plus  élevée  en  fonction 
des  incertitudes  connues. 

Imaginons  une  société  informatique  B  en  concurrence  potentielle,  pour  une  migration 
informatique  internationale  avec  une  autre  société  A  (cette  dernière  pouvant  être  vue  comme 
un  ensemble  de  concurrents  aussi!). 

En  simplifiant  quelque  peu,  mais  sans  être  toutefois  hors  de  la  réalité,  considérons  que  deux 
choix  sont  ouverts  à  B:  viser  "cher"  ou  viser  "bas". 

Supposons  que  nous  savons  également  que  dans  le  passé  B  a  soumis  une  proposition  pour 
chaque  appel  d'offres  de  ce  type,  alors  que  le  groupe  A  ne  l'a  fait  que  dans  60%  des  cas  (pas 
de  fonction  de  distribution  de  probabilité  dans  notre  scénario!). 

Nous  savons  également  que: 

-  Si  B  soumet  cher  et  est  le  seul  à  soumettre  une  proposition,  le  bénéfice  attendu  est  de 
22  millions. 

-  Si  B  soumet  un  prix  élevé  mais  se  trouve  en  concurrence  avec  le  groupe  A,  il  obtiendra 
le  contrat  selon  le  niveau  de  prix  demandé  par  le  groupe  A.  Dans  ce  cas,  il  sait  qu'il 
obtiendra  en  moyenne  1  million. 

-  Si  enfin  B  soumet  à  un  prix  bas,  il  est  sûr  d'obtenir  le  contrat  et  de  réaliser  un  bénéfice 
de  10  millions. 

Donc  dans  le  cadre  où  le  choix  du  projet  est  déterminé  uniquement  par  son  prix  (au  détriment 
de  la  qualité  comme  dans  la  réalité...)  la  question  qui  se  pose  est  alors  la  suivante:  Que  doit 
faire  B,  si  aucune  information  complémentaire  ne  peut  être  obtenue? 

Remarque :  Ceci  constitue  une  situation  du  type  "décision  sans  information" 

Pour  répondre  à  cette  question,  nous  représentons  tout  d'abord  le  problème  à  résoudre  sous 
une  forme  graphique  fort  logique  (qui  est  pour  l'instant  assez  simple  à  mettre  aussi  sous  forme 
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de  tableau)  avec  le  logiciel  TreeAge  (la  même  chose  peut  être  effectuée  avec  Isograph  mais 
cela  prend  trop  de  temps  avec  MS  Visio): 


<1  1 


<]  22 


Ensuite  en  lançant  le  calcul  de  l'espérance  à  chaque  branchement,  TreeAge  nous  donne 
simplement: 


Concurrence 


Cher 


Appel  Offre 


-CX  9.40 

X1 


0.60 
oncurrence 


CK  Pas  cher:  10.00 


\  Pas  cher 


0.40 


<1 

< 


<] 


10.00;  P  =  1.00 


1.00 


22.00 


Ainsi,  la  réponse  à  la  première  question  est  que  la  stratégie  donnant  l'espérance  de  gain  la  plus 
grande  est  la  stratégie  "Pas  Cher"  car  il  y  a  un  gain  espéré  de  10  millions. 

Avec  la  première  décision  (Cher)  nous  gagnerions  en  moyenne  que: 


22  0.4  +  1  0.6  =  9.4 


Remarque:  Dans  les  arbres  de  décisions  construites  avec  TreeAge  une  règle  de  base  est 
d'avoir  à  chaque  branche  probabiliste  la  somme  des  probabilités  qui  vaut  1  ! 

Cette  méthode  est  simple  à  mettre  en  place  mais  dès  que  les  scénarios  se  compliquent  il  faut 
alors  faire  appel  aux  probabilités  bayésiennes  ou  aux  simulations  de  Monte-Carlo  et  alors 
l'affaire  se  complique  nettement! 

8. 6. 3.4. 8. 8  Analyses  procédurale  hiérarchique 

L'APH  est  une  technique  d'analyse  décisionnelle  multicritère  ("Multi  Criteria  Decision 
Making"  (MCDM)  en  anglais)  utilisée  quasi  exclusivement  dans  les  grandes  multinationales 
et  gouvernement  américaines  pour  prendre  des  décisions  déterministes  complexes. 

Nous  savons  que  les  systèmes  de  votes  traditionnels  ou  de  notes/rangs  ne  peuvent  pas  être 
utilisés  dans  le  cadre  de  décisions  complexes  multicritères  et  multi-niveaux  car  ces  derniers  ne 
prennent  trivialement  pas  en  compte  le  poids  d'importance  associés  aux  composants.  De  plus, 
même  si  un  poids  était  affecté  le  problème  résider  dans  le  choix  d'une  valeur  empirique  de  ce 
dernier  ce  qui  rend  l'approche  totalement  non  scientifique  et  ouvre  la  porte  à  des  débats 
interminables  dans  la  pratique. 

Pour  présenter  la  technique  de  l'APH  il  nous  semble  pertinent  de  commencer  avec  un  exemple 
d'analyse  naïve  d'une  somme  de  scores  (notes): 
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Critère/ Alternative 

Choix  de  X 

Choix  de  Y 

Choix  de  Z 

Plage 

Facteur  A 

1 

4 

5 

0-5 

Facteur  B 

20 

70 

50 

1-100 

Facteur  C 

-2 

0 

1 

-2  à +2 

Facteur  D 

0.4 

0.75 

0.4 

Oà  1 

Somme 

19.4 

74.75 

56.4 

Score  normalisé 

12.9% 

49.7% 

37.5% 

Cependant,  vous  remarquerez  que  la  plage  de  valeurs  pour  chaque  facteur  du  produit/projet 
n'est  pas  la  même.  Il  est  alors  tout  à  fait  injuste  de  résumer  toutes  les  valeurs  de  plusieurs 
critères  et  comparer  le  résultat.  Il  est  clair  que  le  facteur  B  est  dominant  parce  que  la  gamme  a 
une  valeur  plus  élevée.  Pour  être  juste,  nous  pouvons  proposer  au  moins  deux  solutions 
triviales: 

1.  Au  lieu  d'utiliser  des  valeurs  arbitraires  pour  chaque  facteur,  nous  positionnons  juste  le 
choix  pour  chaque  facteur:  la  valeur  de  rang  plus  petit  est  plus  préférable  que  celle  de  rang 
supérieur  (c'est  psychologie  par  rapport  à  l'usage  quotidien  de  la  majorité  des  humains). 

2.  Nous  transformons  la  valeur  du  score  de  chaque  facteur  en  fonction  de  la  valeur  de  plage  de 
sorte  que  chaque  facteur  aura  la  même  étendue  (normalisation  des  scores). 

Essayons  les  deux  solutions  en  commençant  par  la  première: 


Critère/Alternative 

Choix  de  X 

Choix  de  Y 

Choix  de  Z 

Facteur  A 

3 

2 

1 

Facteur  B 

3 

1 

2 

Facteur  C 

3 

2 

1 

Facteur  D 

2 

1 

2 

Somme 

11 

6 

6 

Score  normalisé 

26.09% 

36.96% 

36.96% 

où,  puisque  la  plus  petite  valeur  de  rang  est  la  meilleure,  nous  avons  renormalisé  les  codes  de 
la  façon  logique  suivante: 

1.  Comme  la  somme  de  tous  les  rangs  est  toujours  égale,  soustraire  du  total  des  rangs  RT  la 

somme  des  rangs  d'une  colonne  RCi  a  pour  effet  automatiquement  de  lui  donner  l'importance 

inverse  (effectivement  si  la  somme  totale  des  rangs  vaut  23  comme  ci-dessus  alors  23-6=17 
alors  que  23-11=12  donc  nous  avons  bien  l'effet  recherché).  Nous  avons  alors  la  somme  des 
rangs  normalisée: 


Ra 


2.  Nous  voulons  un  pourcentage,  dès  lors  il  est  naturel  d'écrire: 


Rr  —  Rr.  Rr- 

%srn;  =  — - —  =  1 - - 

'  rt  rt 


3.  Le  problème  de  ce  dernier  calcul  c'est  qu'il  donne  systématiquement  sommé  pour  toutes  les 
colonnes  200%.  Il  faut  alors  le  multiplier  par  0.5  tel  que  au  final: 
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Vincent  ISOZ 


%SRm  =  0.5 


(  D  3 

\  _  ^C' 


R 


T  J 


Maintenant  il  est  important  de  remarquer  que  le  fait  de  travailler  avec  les  rangs  ne  donne  plus 
le  même  résultat  que  dans  le  tableau  antéprécédent.  Effectivement,  les  choix  y  et  Z  deviennent 
indifférents  et  donc  nous  avons  perdu  de  l'information! 

Raison  pour  laquelle  est  il  recommandé  de  travailler  sur  les  scores  plutôt  que  les  rangs  car  non 
seulement  travailler  sur  les  rangs  peut  amener  à  des  égalités  qui  n'avaient  pas  lieu  d'être  mais 
dans  certains  cas  cela  inverse  même  le  rang  final  de  certains  éléments  d'un  choix  (nous 
parlons  alors  "d'effet  d'inversion  de  rang  par  les  scores"). 

Maintenant  voyons  l'effet  qu'aurait  de  normaliser  les  scores  du  premier  tableau  entre  0  et 
100%  en  utilisant  simplement  une  règle  de  trois  (après  décalage  des  scores),  le  tableau 
suivant: 


Critère/ Alternative 

Choix  de  X 

Choix  de  Y 

Choix  de  Z 

Plage 

Facteur  A 

1 

4 

5 

0-5 

Facteur  B 

20 

70 

50 

1-100 

Facteur  C 

-2 

0 

1 

-2  à +2 

Facteur  D 

0.4 

0.75 

0.4 

Oà  1 

Somme 

19.4 

74.75 

56.4 

Score  normalisé 

12.9% 

49.7% 

37.5% 

Devient  alors: 

Le  calcul  est  clairement  un  peu  plus  compliqué  qu'avec  les  rangs  mais  nous  avon  un  résultat 
meilleur  dans  le  sens  que  la  conclusion  n'est  pas  changée. 

Maintenant  voyons  une  version  naturellement  plus  évoluée  inspirée  des  portefeuilles 
financiers  incluant  des  poids  aux  critères.  Évidemment  le  résultat  de  l'exemple  qui  suit  ne  sera 
plus  comparable  aux  précédents. 

Donc  considérons  le  tableau  de  poids  suivant: 


Facteur  A 

Facteur  B 

Facteur  C 

Facteur  D 

Somme 

Poids 

6 

2 

2 

1 

11 

Poids  relatifs 

54.5% 

18.2% 

18.2% 

9.1% 

100% 

Notre  tableau  des  scores  normalisés  devient  alors: 


Critère/ Alternative 

Poids 

Choix  de  X 

Choix  de  Y 

Choix  de  Z 

Facteur  A 

54.5% 

0.109 

0.436 

0.545 

Facteur  B 

18.2% 

0.035 

0.127 

0.090 

Facteur  C 

18.2% 

0.000 

0.091 

0.136 

Facteur  D 

9.1% 

0.036 

0.068 

0.036 

Somme 

100% 

0.180 

0.722 

0.808 

Score  normalisé 

10.5% 

42.2% 

47.2% 
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Bon  ces  techniques  élémentaires  décisionnelles  ayant  été  présentées  passons  maintenant  à 
l'APH  à  proprement  parlé  qui  a  une  approche  complément  différente! 

Remarque :  Signalons  que  l'auteur  de  cette  méthode  (Thomas  Saaty)  a  édité  un  logiciel  qui 
permet  d'automatiser  des  procédures  complexes  de  décision  basées  entre  autres  sur  sa 
méthode  et  qu'il  est  possible  de  retrouver  à  l'adresse  suivante  http://www.superdecisions.com. 

L'approche  de  l'APH  se  veut  déjà  être  très  mathématique.  Dès  lors  intuitivement  nous 
pouvons  déjà  nous  dire  que  les  scores  normalisés  sont  en  réalité  les  composantes  d'un  vecteur 
de  poids  de  préférence  dont  la  somme  vaut  100%: 


w  = 


Ensuite  la  deuxième  idée  est  de  comparer  via  une  matrice  pour  un  facteur  donné  les  choix  qui 
sont  à  disposition  (dans  le  but  évidemment  d'avoir  une  approche  utilisant  la  puissance  de 
l'algèbre  linéaire).  Par  exemple  en  reprenant  nos  tableaux  ci-dessus  et  en  focalisant  sur  la 
Facteur  A,  nous  aurions: 


Facteur  A 

Choix  A 

Choix  B 

Choix  C 

Choix  A 

1 

? 

? 

Choix  B 

? 

1 

? 

Choix  C 

? 

? 

1 

Les  valeurs  (scores)  de  la  diagonale  sont  évidentes  car  chaque  choix  ne  peut  pas  être  préféré  à 
lui-même  que  dans  une  relation  autre  qu'une  égalité  unitaire  stricte. 

Déjà  deux  questions  peuvent  se  poser  à  ce  niveau: 

Ql.  Sachant  que  les  scores  (parfois  appelés  "stimulis")  doivent  avoir  une  forme  de  symétrie, 
combien  de  scores  en  fonction  du  nombre  de  choix  n  devra  faire  un  "juge". 

Q2.  Quelle  échelle  de  score  ("stimuli")  choisir  et  quelle  relation  de  symétrie  (par  exemple 
entre  Choix  B-Choix  A  et  Choix  A-Choix  B  car  si  nous  devons  choisir  l'un,  l'autre  doit 
découler  automatiquement). 

Pour  répondre  à  la  première  question  nous  pouvons  construire  un  simple  tableau  (il  s'agit  donc 
simplement  du  nombre  de  cas  au-dessous  ou  respectivement  en  dessous  de  la  diagonale  de  la 
matrice  de  préférence): 


Nbr.  de  choix 

1 

2 

3 

4 

5 

6 

7 

n 

Nbr.  de 
comparaisons 

0 

1 

3 

6 

10 

15 

21 

n{n- 1) 

2 

Pour  répondre  à  la  deuxième  question  il  vaut  mieux  se  mettre  dans  la  peau  d'un 
mathématicien,  ingénieur  ou  statisticien.  Déjà  sachant  que  l'égalité  est  logiquement  "1"  il 
serait  mal  venu  de  prendre  l'ensemble  des  réels  avec  des  valeurs  négatives  pour  la  réciproque 
sachant  que  dans  ce  cas  l'égalité  devrait  être  zéro  et  non  plus  1.  Ceci  dit  prendre  une  matrice 
de  préférence  dont  la  diagonale  serait  des  zéros  reviendrait  à  utiliser  des  techniques  propres  au 
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Data  Mining  puisque  cela  revient  à  avoir  une  matrice  des  distances.  Mais  le  problème  des 
matrices  des  distances  dans  le  contexte  qui  nous  intéresse  ici  c'est  que  les  composantes  sont 
symétriques  et  dans  le  cas  des  préférences  cela  n'est  pas  de  sens! 

Donc  notons  la  matrice  carrée  des  scores  de  la  manière  suivante: 


A  =  (aij)  = 


Une  piste  serait  de  se  dire  que  puisque  nous  avons  un  vecteur  des  poids  w ,  il  faudrait  opérer 
entre  la  matrice  des  préférences  et  ce  vecteur  des  poids  d'une  manière  ou  d'une  autre.  Or,  en 
pensant  au  fait  que  dans  le  domaine  des  Statistiques  nous  retrouvons  souvent  le  concept  de 
vecteur  et  de  valeur  propre  alors,  le  choix  de  la  multiplication  s'impose  de  façon  assez 
naturelle: 


1  a 


12 


Cl, 


in 


a2\  1  *  *  *  U2n 


an\  an2 


a 


a 


12 


a , 


a 


21 


in 


*2  n 


an\  an2  ■■■  1 


\WnJ 


Maintenant,  le  fait  d'avoir  pris  la  multiplication  nous  donne  une  piste  sur  le  choix  des 
composantes  de  la  matrice  des  préférences.  Effectivement,  si  nous  prenons: 


1  an  • 

■■  «1  n 

W  j  /  wx  W  j  /  w2 

•• 

«21  1  • 

■■  a2n 

= 

w2/vq  w2/w2  • 

••  w2/wn 

_üni  ün2 

■■  1 

âT 

"  ^ 
_ 1 

■■  Wn/Wn_ 

W1 

'Wi 

=  n 

,  w„  , 

,  W„  , 

nous  avons  une  relation  entre  un  vecteur  propre  et  une  valeur  propre  entière  via  une  matrice 
(application  linéaire)  dont  les  composantes  sont  les  préférences.  Remarquez  aussi  au  passage 
que  la  somme  des  valeurs  d'un  colonne  i  est  égale  à  1  /  wt .  Et  si  nous  observons  bien  nous 
avons  en  réalité: 


W1 

/  wx 
/  wx 

wl/w2  • 
w2/w2  • 

■■  wllwn 
■■  w2/wn 

ïT  ••• 

V _ 

1 

1/ «12 

«12 

1 

••  «1» 

r 

$  ••• 

v _ 

W2 

= 

••  «2  n 

=  n 

J Wn 

/  w1 

wnlw2  ■ 

■■  wnlwn_ 

KWnj 

_l/am 

1  /  «2n  • 

••  1 

Ce  qui  revient  à  avoir  un  problème  aux  vecteurs  et  valeurs  propres  (cf.  chapitre  d' Algèbre 
Linéaire): 

(A  -  ni)  w  =  Ô 

Étant  donné  le  polynôme  caractéristique  suivant  (cf.  chapitre  d' Algèbre  Linéaire): 
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det  (A-  A/2)  = 


A 

a2l  a22 


*12 


-  ^  -  Cflll  +fl22) +  (flllfl22  -  fl21fl12) 


"ÏkST 


detU) 


ou  encore  suivant  (cf.  chapitre  d' Algèbre  Linéaire): 


1 - 1 

1 

a\2 

a13 

det  (A  -  ÂI3  )  = 

1— 1 

y 

a22  ~  ^ 

a23 

a3\ 

a32 

A 

--A3  +  (flj  j  +  fl22  +  ^33)  ^  -  (flllfl33  +  ^22^33  +  a\ lfl22  -  a32a73  -  ^12^21  -  fl31fl13) 


+  (£ï11ü22æ33  ~a\\a32a23  ~a12a2la33  +  ^31^23^12  +  a\3a21a32  ~  a13a31a22) 
‘ - , - ’ 

detf.4) 


Au  vu  de  la  construction  de  la  matrice  des  préférences,  nous  voyons  alors  que: 

det(A-A/2)  =  A2  -2A  +  1-1  =  A2  -2/1  =  0 


et  donc  il  n'y  a  qu'une  seule  valeur  propre,  elle  est  entière  et  vaut  bien  A  =  n  =  2 .  Nous  disons 
alors  que  toute  matrice  carrée  réciproque  de  dimensions  2  est  consistante. 

Passons  à  une  dimension  supérieure: 

det  (A  —  A/j  ^  =  — A^  +  3A2  +  (A  —  1  —  1  +  ^31^23^12  +  ^13^21^32  —  l) 

=  — A  +  3 A  +  ^31^23^12  ^13^21^32  —  2  =  0 

Nous  disons  dans  ce  cas  que  toute  matrice  carrée  réciproque  de  dimensions  3  n'est  pas 
nécessairement  consistante.  Pour  que  cela  soit  le  cas,  il  faudrait  que: 

^31^23^12  ^13^21^32  2  —  D 

et  seulement  dans  ce  cas  nous  aurons  une  seule  valeur  propre  A  =  n  =  3 .  Remarquez  que  si 
nous  écrivons  cette  dernière  relation  sous  la  forme: 

ajkaijaki+akjaikaji  -  2  =  ° 


Alors  si: 


ajkaij  =aik 

la  matrice  est  consistante.  Nous  verrons  un  peu  plus  loin  l'impact  pratique  qu'à  cette  dernière 
égalité. 

Il  faut  bien  évidemment  au  besoin  normaliser  le  vecteur  propre  afin  que  la  somme  des  poids 
de  préférence  soit  unitaire  tel  que: 
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Donc  cela  nous  amène  à  avoir  si  nous  jugeons  notre  préférence  sur  une  échelle  du  type 
suivant  pour  nos  trois  choix  du  Facteur  A: 

[Choix  A]  98765432123456789  [Choix  B] 

[Choix  A]  98765432123456789  [Choix  C] 

[Choix  B]  98765432123456789  [Choix  C] 

et  en  faisant  bien  attention  à  mettre  les  préférences  directes  dans  la  partie  supérieure  de  la 
matrice  et  l'inverse  dans  la  partie  inférieure  (sinon  quoi  le  vecteur  propre  ne  sera  pas  le  même 
et  in  extenso  les  poids  aussi!): 


Facteur  A 

Choix  A 

Choix  B 

Choix  C 

Choix  A 

1 

1/3 

5 

Choix  B 

3 

1 

7 

Choix  C 

1/5 

1/7 

1 

Dans  l'exemple  ci-dessus  les  préférences  sont  consistantes  car  si  B  est  préféré  à  A  (6  ^  4  )  et 
A  est  préféré  à  C  (  A  y  C  ),  nous  devrions  alors  avoir  logiquement  B  y  C  et  qui  est  bien  le 
cas  ici.  Dans  le  cas  contraire  nous  disons  que  les  choix  sont  inconsistants.  Cette  consistance  se 
résume  par  la  relation  vue  plus  haut  où  dans  le  cas  idéal  nous  devrions  avoir: 

ajkaij  =aik 

Soit  pour  être  consistant  nous  allons  nous  intéresser  à  la  combinaison  faisant  intervenir  les 
choix  C  et  B,  c'est-à-dire: 


aj3a2 j  ~  a23  — ^  aACaBA  —5-3  —  15 


Donc  pour  être  totalement  consistants  nous  devrions  avoir  pour  aBC  la  valeur  de  15  mais  ce 

n'est  pas  quelque  chose  que  nous  pouvons  exiger  pratiquement  parlant.  Cependant  l'écart  à  la 
consistance  parfaite  va  générer  des  valeurs  propres  supplémentaires  autre  que  l'unique  valeur 
propre  qui  vaut  n  lorsque  la  consistance  est  parfaite.  Dès  lors,  une  mesure  possible  de 
l'inconsistance  est  la  moyenne  des  valeurs  propres  autres  que  la  principale: 


1 


n  - 1 


2A 


i= 2 


qui  en  cas  de  consistance  parfait  est  donc  nul. 

Pour  simplifier  le  calcul  de  CI,  nous  allons  utiliser  le  fait  que  nous  avons  démontré  dans  le 
chapitre  d' Algèbre  Linéaire  que  la  trace  d'une  matrice  est  égale  à  la  somme  de  ces  valeurs 
propres.  Donc  nous  pouvons  écrire: 
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(a)  —  fl  —  —  ^max  +  O  —  n  J'n 


i= 1 


i=2 


i-2 


D'où  un  choix  possible  pour  mesure  la  consistance: 


n  -  /L 


n  - 1 


Mais  par  tradition  nous  prenons  la  valeur  négative  de  cette  relation  comme  définition  du 
"critère  de  consistance": 


CI  = 


/L 


-n 


n- 1 


Donc  ci-dessus,  par  exemple,  le  choix  B  a  été  noté  3  par  rapport  au  choix  A  (donc  B  est 
préféré  à  A).  Déterminé  le  poids  des  préférences  revient  donc  à  un  problème  de  vecteurs  et 
valeurs  propres: 


f 

"  1 

1/3 

5" 

A 

fw0 

w2 

( 

~  i 

1/3 

5" 

w2 

3 

1 

7 

-ni 

= 

1 

3 

1 

7 

-1 

V 

1/5 

1/7 

1 

J 

yWny 

n 

K 

1/5 

1/7 

1 

) 

vwJ 

où  il  ne  faut  pas  oublier  que  multiplier  une  matrice  avec  un  scalaire  revient  à  multiplier  les 
valeurs  propres  par  ce  même  scalaire  (et  non  directement  les  composantes  des  vecteurs 
propres).  Raison  pour  laquelle  que  nous  cherchions  les  vecteurs  propres  de  la  matrice  des 
préférences  ou  de  la  matrice  des  préférences  normalisée  par  1/n  les  vecteurs  propres  seront  les 
mêmes! 

Donc  en  faisant  des  calculs  à  la  main  ou  par  ordinateur  (cf.  chapitre  d'Algèbre  Linéaire),  nous 
obtenons: 


'  0.397989  " 

^27.895%^ 

w  = 

= 

0.914031 

^WN  = 

64.911% 

v0.1012818 J 

v07.192%y 

Mais  les  trois  valeurs  propres  ne  sont  pas  nulles  car  nous  avons: 

\  =  3.06488,  À2  =-0.324438  +  0.447702/,  4,  =-0.0324438-0.447702/ 


et  nous  savons  que  cela  vient  du  fait  de  la  faible  non  consistance  de  notre  matrice  des 
préférences.  Nous  avons  alors  pour  critère  de  consistance: 


CI  = 


3.06488-3 

3-1 


0.03244 


OK  c'est  proche  de  0  donc  a  priori  c'est  une  bonne  consistance.  Mais  pour  avoir  un  jugement 
scientifique  sur  cette  valeur  le  mieux  reste  encore  de  faire  des  milliers  de  simulations  de 
matrices  avec  des  jugements  tirés  au  hasard  consistants  ou  non  et  de  calcul  leur  consistance 


Ingénierie  de  Gestion  de  projets 


359/547 


moyenne.  Ainsi  d'après  l’article  original,  avec  50’000  simulations  nous  obtenons  pour  chacune 
des  matrices  de  préférence  de  taille  n  un  indice  aléatoire  de  consistance  (noté  RI  pour 
"random  index"): 


n 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

RI 

0 

0.52 

0.89 

1.11 

1.25 

1.35 

1.40 

1.45 

1.49 

Remarque :  Dans  la  pratique  il  est  conseillé  de  ne  pas  dépasser  n  valant  7  car  au-delà  l'esprit 
humain  à  de  la  peine  à  conceptualiser  rapidement. 

Donc  dans  le  cas  de  notre  exemple,  nous  avons  la  ratio  de  consistance: 


C7  _  0.03244 
RI  ~  0.52 


0.0623 


Et  évidemment  plus  ce  ratio  est  petit  (dans  le  sens  inférieur  à  l'unité!)  mieux  c'est.  Il  est 
d'usage  dans  la  pratique  de  dire  que  si  ce  ratio  est  inférieur  à  0. 1  alors  l'inconsistance  est 
acceptable  (et  donc  la  consistance  est  bonne). 

Voyons  maintenant  un  cas  multi-niveaux  de  l'APH. 

Exemple: 

Considérons  que  nous  devons  choisir  parmi  4  voitures  sur  la  base  de  3  critères: 


Objectif: 

Choisir  un  voiture 


Style 

Fiabilité 

Consommation 

—Civic 

—Civic 

—Civic 

—Saturn 

—Saturn 

—Saturn 

— Escort 

— Escort 

— Escort 

—Clio 

—Clio 

—Clio 

Supposons  que  la  matrice  des  préférences  soit  trois  premiers  critères  techniques  soit: 


Technique 

Style 

Fiabilité 

Consommation 

Style 

1 

1/2 

3 

Fiabilité 

2 

1 

4 

Consommation 

1/3 

1/4 

1 

En  faisant  les  mêmes  calculs  que  plus  haut  ou  en  s'aidant  d'un  logiciel,  nous  obtenons: 
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Maintenant  nous  faisons  le  deuxième  niveau,  c'est-à-dire  la  matrice  de  préférence  des  voitures 
pour  le  style  (comparaison  par  paire  des  styles  donc. . .): 


Voiture  Style 

Civic 

Saturn 

Escort 

Clio 

Civic 

1 

1/4 

4 

1/6 

Saturn 

4 

1 

4 

1/4 

Escort 

1/4 

1/4 

1 

1/5 

Clio 

6 

4 

5 

1 

Et  nous  faisons  de  même  pour  les  deux  autres  critères  pour  obtenir: 


Il  s'agit  maintenant  de  combiner  ces  deux  niveaux!  Pour  cela  il  semble  intuitif  de  faire  la 
multiplication  matricielle  (pondération)  suivante: 


"0.1160 

0.3790 

0.3010" 

"0.3060" 

Civic 

"0.3196" 

0.2470 

0.2900 

0.2390 

0.5584 

_ 

0.2720 

_ 

Saturn 

0.0600 

0.0740 

0.2120 

0.1220 

0.0940 

Escort 

0.5770 

0.2570 

0.2480_ 

_0.3280_ 

dio 

Donc  la  Clio  sort  gagnante  de  cette  APH! 
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Une  grande  partie  de  ce  que  nous  venons  de  voir  en  ce  qui  concerne  la  phase  d'identification 
peut  se  résumer  au  schéma  non  normalisé  suivant: 


Cahier  des  charges 
et  spécifications 
client 


source:  ©ANCORE  Managementlwww.ancoremanagement.eu 
POURQUOI? 


i-l-i-i-i-ï-i'ivâasààiBBiÈBvirï-K'ï'ï-ï-i-i'#'  ■iï-i-i'i'iiiâiiiââiiiiiëii'i'rri'l 


Arborescence  |  QfJQJ? 


liflaailllBiftiïifeiêrf 

JL.  L . 


technique  (AT) 


Structure  hiérarchisée 
du  travail  (SHT) 


COMMENT? 


Xtt  Z 


Organigramme  des  taches  (OT) 
AT 


SHT 


Structure  de 

Ordre  de 

contribution 

1  :  fabrication  (OF) 

QUI?  - ►  LOTS  DE  TRAVAUX 


QUAND? 


Ré  s  eau  logique 
(PERT,  CPM,  MPM) 

^ — 

Diagramme  de 
Gantt 

AVEC  QUELS  MOYENS 


Plans  de  charges 
jrévisionnels 


)  lr~V 


COMBIEN? 


Figure  36Résumé  phase  identification 

8.6.4  Réalisation  (pilotage) 


lit 

Executing  Kick-off  meeting 


k 


Distributing  Information 


Coordinating  Project  Work 


X 

Ëk  •  jMà 

Coordinating 
People  and  Resources 


Quality  Assurance 


Après  avoir  identifié  les  diverses  composantes  du  projet,  il  faut  maintenant  faire  du  modèle 
informatisé  une  exécution  réelle  sans  avoir  oublié  de  définir  et  convenir  des  plans  de 
déploiement  et  de  mise  en  production  avec  les  clients  et  les  parties  prenantes  et  ce  tout  en 
surveillant  le  triangle  d'or  du  responsable  de  projet  (la  sainte  trinité. . .): 
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et. . .  en  prenant  en  compte  avec  évidence  le  "paradoxe  de  la  gestion  de  projets": 


"  We  can  do  GOOD,  QUICK  and  CHEAP  work. 

You  can  hâve  any  two  but  not  ail  three. 

1 .  GOOD  QUICK  work  won't  bc  CHEAP. 

2.  GOOD  CHEAP  work  won’t  be  QUICK. 

3.  QUICK  CHEAP  work  won't  be  GOOD." 


ou  autrement  présenté  et  en  français: 


Rapide 


ça  risque  ça  coûtera 

d’être  mauvais  plus  cher 

ce  sera 
NON 

ça  risque 
d'être  lent 

cher  Qualité 


Nous  savons  que  faire  un  modèle  du  planning  (projet)  consiste  à  notre  époque  se  familiariser 
avec  le  logiciel  de  gestion  de  projets,  à  créer  un  fichier  projet,  à  saisir  et  à  manipuler  les 
tâches  entourant  le  projet  en  tenant  compte  de  leur  durée,  et  à  hiérarchiser  les  tâches  sous 
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forme  de  phases.  De  plus,  il  faut  répartir  les  unités  de  ressources  humaines  et  matérielles  entre 
les  tâches  reliées  au  projet,  en  plus  de  saisir  les  coûts  des  ressources  sur  ordinateur. 

Grâce  à  la  phase  de  planification  et  au  logiciel  de  gestion  de  projets,  le  coordinateur  du  projet 
sera  en  mesure  de  gérer  son  projet  de  façon  "proactive"  (...)  et  ce  en  appliquant  les  règles  de 
l'art  en  gestion  de  projets.  Principalement,  ces  outils  lui  permettront  de  faire  ce  qu'un 
gestionnaire  de  projets  est  toujours  censé  faire  soit:  interagir  avec  les  différents  intervenants 
externes  et  internes  gravitant  autour  du  projet. 

La  phase  de  pilotage  informatisée  est  également  appelée  "étape  de  contrôle  et  suivi".  Plusieurs 
activités  sont  au  centre  de  cette  phase: 

■  Recueil  des  informations  sur  le  déroulement  réel  du  projet  pour  contrôler  la  durée  des 
tâches,  le  volume  des  ressources  affectées  à  celles-ci,  etc. 

■  Évaluation  des  résultats  recueillis  et  diagnostic  (audit) 

■  Décisions  correctives  en  fonction  du  diagnostic  (leveling,  delay,  etc.) 

■  Information  de  l'ensemble  des  acteurs  concernés  des  corrections  effectuées  (MS 
Project  Server  avec  MS  Project  et/ou  SharePoint) 

En  fonction  des  trois  catégories  d'objectifs  définis  pour  un  projet,  trois  procédures  de  contrôle 
et  suivi  peuvent  être  mises  en  place: 

■  Contrôle  et  suivi  de  la  programmation  (suivi  des  dates) 

■  Contrôle  et  suivi  des  coûts 

■  Contrôle  et  suivi  de  la  qualité  ou  des  performances  techniques 

Cette  phase  favorise  le  contrôle  et  le  respect  des  échéanciers,  des  budgets  et  de  la  qualité  du 
produit  et/ou  du  service.  Pour  ce  faire,  le  diagramme  de  Gantt,  présenté  plus  loin,  n'est  qu'un 
des  outils  offerts  au  gérant  de  projet.  Il  permet  de  corriger  ou  de  justifier  les  écarts  pouvant  se 
produire  tout  au  long  du  projet. 

Pour  s'assurer  que  la  phase  de  pilotage  soit  efficace,  il  faut  établir  des  lignes  de  conduite  qu'on 
doit  essayer  de  suivre: 

■  Mettre  sur  pied  une  équipe  de  projet  multidisciplinaire,  s'il  y  a  lieu 

■  Répéter  continuellement  les  objectifs  par  rapport  au  projet  et  au  produit 

■  Définir  et  gérer  un  plan  bien  documenté 

■  Définir  clairement  les  attentes  du  projet 

■  Gérer  d'une  façon  efficace  les  échéanciers 

■  Créer  une  base  de  données  pour  le  projet 

■  Faire  un  audit  sur  une  base  périodique  après  chaque  phase,  s'il  y  a  lieu 
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■  Encourager  les  membres  de  l'équipe  à  utiliser  des  outils  informatiques  pour  la  gestion, 
la  coordination  et  le  contrôle  du  projet. 

■  Autres  (tenir  des  rencontres  régulièrement,  préparer  des  rapports  de  rendement  sur  les 
ressources  et  les  tâches  reliées  au  projet,  etc.) 

La  gestion  d'un  projet  suppose  la  coordination  efficace  des  activités  et  le  contrôle  du 
rendement  en  termes  de  coûts,  de  temps  d'achèvement  physique  de  chaque  activité.  La  figure 
ci-dessous  montre  un  modèle  de  contrôle  à  rétroaction.  Les  objectifs  et  les  normes  de 
rendement  du  projet  sont  établis  à  partir  du  processus  de  planification.  Le  processus  de 
contrôle  permet  d'évaluer  les  écarts  entre  les  prévisions  et  les  résultats. 

Prenons,  par  exemple,  un  projet  où  il  n'existe  aucun  écart  entre  les  coûts  budgétisés  et  les 
coûts  réels,  mais  où  l'on  retrouve  une  différence  entre  le  temps  d'achèvement  probable  et  le 
temps  d'achèvement  réel  d'une  tâche  du  projet.  Le  responsable  de  cette  activité  du  projet  devra 
alors  examiner  cet  écart  et  expliquer  les  raisons  pour  lesquelles  on  n'a  pas  respecté  la  durée 
initialement  prévue.  Il  faut  réviser  les  objectifs  si  des  dérives  sont  constatées  au  cours  de  la 
réalisation. 


Processus  de 
-[planification 


Réévaluation  1 

s. 

des  objectifs  1 

Établir  les  I  Prédire  les 

^TrB 


Écarts 

favorables  ou 
défavorables 


Processus  de  contrôle 


Évaluer  les  écarts 
et  prendre  des 
mesures  collec¬ 
tives,  s'il  y  a  fieu 


La  figure  suivante  illustre  la  démarche  du  processus  de  contrôle  du  projet.  Elle  commence 
avec  l'établissement  d'une  planification  initiale  qui  montre  comment  la  portée  du  projet  va  être 
accomplie  avec  un  échéancier  prévu  et  un  budget  préétabli.  Une  période  de  rapportage  doit 
être  établie  pour  la  comparaison  du  progrès  actuel  avec  le  progrès  planifié.  Pendant  la  période 
de  rapportage  il  y  a  deux  sortes  d'information  à  rassembler,  les  informations  sur  la 
performance  actuelle  et  les  informations  sur  les  changements  dans  la  portée,  l'échéancier  et  le 
budget.  Dans  le  cas  de  changement,  il  est  conseillé  de  produire  une  nouvelle  planification 
initiale.  Le  processus  de  contrôle  de  projet  continue  pendant  le  déroulement  du  cycle  de  vie 
du  projet.  La  plupart  du  temps,  une  période  de  rapportage  courte  aide  à  identifier  les 
problèmes  plus  tôt  pour  faciliter  les  actions  correctives. 

Les  outils  d'évaluation  des  résultats  du  projet  sont  présentés  ci-dessous: 

■  □  Rapports  d'écarts  (prévisions  vs  réels) 

■  Diagramme  de  tâches  de  Gantt  (durées,  coûts,  etc.) 

■  Rapport  d'avancement  du  projet 
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■  Rapport  sur  les  ressources  affectées  aux  tâches  liées  au  projet 

■  Charge  de  travail  du  projet  et  affectations 

■  Résumé  sur  les  tâches  périodiques 

■  Graphique  sur  les  ressources  surutilisées 

■  Autres  (Pert  et  Gantt,  échéancier,  etc.). 

L'état  des  mouvements  de  trésorerie  par  rapport  à  chaque  tâche  du  projet,  les  rapports  d'écarts 
sur  les  ressources  affectées  au  projet,  les  diagrammes  de  tendance  de  coûts,  etc.,  peuvent  tous 
être  préparés  pour  aider  le  coordinateur  du  projet  à  évaluer  le  rendement  de  ses  subalternes  et 
d'autres.  Des  exemples  de  ce  type  de  rapports  peuvent  être  obtenus  avec  MS  Project, 

MS  Excel,  MS  Access,  Business  Objects  ou  encore  Crystal  Reports. 

Ce  n'est  pas  parce  qu'une  femme  fait  un  bébé  en  neuf  mois,  que  neuf  femmes  feraient  un  bébé 

en  un  mois...45 


45  Petite  boutade  indiquant  que  dans  certains  projets  l'ajout  de  ressource  ne  permet  ni  d'aller  plus  vite,  ni  de 
rattraper  le  temps  perdu  (pour  des  raisons  de  complexité  du  projet). 
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8.6.4. 1  Engineering 

Nous  allons  juste  parler  ici  de  vocabulaire  méthodologique  qui  n'a  rien  d'extraordinaire. 
Lorsqu'un  projet  est  en  phase  de  réalisation  (ou  même  parfois  en  phase  d'analyse)  nous 
différencions  (désolé  je  n'ai  jamais  vu  les  termes  équivalents  en  français): 

1.  Le  "white  box  forward  engineering"  qui  consiste  à  réaliser  à  partir  d'un  cahier  des 
charges  ou  d'un  processus  abstrait  le  produit  final  (livrable)  d'un  point  de  vue  micro 
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(plus  petit  de  ses  composants)  et  macro  (interface  homme  machine 
(IHM)/touché/visuel  externe). 

2.  Le  "black  box  forward  engineering  "  qui  consiste  à  partir  d'un  cahier  des  charges  ou 
d'un  processus  abstrait  un  produit  final  (livrable)  qui  vient  se  greffer  ou  se  superposer 
à  une  solution  existante  dont  on  ne  connaît  pas  le  fonctionnement  interne  mais  que  les 
entrées/sorties. 

3.  Le  "white  box  reverse  engineering"  qui  consiste  dans  le  cadre  d'une  réalisation  de 
projet  à  décortiquer  le  fonctionnement  d'un  élément  existant  imposé  dans  l'écosystème 
du  projet  et  ce  en  ayant  accès  de  manière  transparente  jusqu'à  son  plus  petit  élément  et 
à  ses  interactions  avec  l'environnement  technique  ou  naturel  (approche  "atomique"). 

4.  Le  "black  box  reverse  engineering"  qui  consiste  dans  le  cadre  d'une  réalisation  de 
projet  à  décortiquer  le  fonctionnement  d'un  élément  existant  imposé  dans  l'écosystème 
du  projet  et  en  n'ayant  pas  accès  à  l'intérieur  de  l'élément  mais  en  observant  son 
comportement  (output)  à  des  stimulis  externes  (input). 

8. 6.4.2  Gestion  du  changement 


Time 


Les  changements  ont  tendance  à  mener  le  projet  au  chaos  ou  à  générer  des 
conflits/malentendus  au  sein  d'une  équipe  de  projets.  Il  est  donc  très  fortement  conseillé 
d'adopter  une  démarche  formelle  (processus)  pour  évaluer  et  autoriser  le  changement  dès  le 
début. 

1 .  Standardisez  la  demande  de  changement  du  client  suivant  un  formulaire  complet  (voir 
la  liste  des  modèles  fournis  dans  le  cadre  de  ce  cours)  afin  de  ne  rien  omettre. 
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2.  Notez  la  modification  proposée  dans  le  journal  de  bord  dans  un  tableau  comportant  un 
numéro  d'identifiant  du  projet,  un  numéro  d'identifiant  du  changement,  l'initiateur,  la 
date  de  proposition,  le  nom  de  l'approbateur,  l'état  d'approbation  (Oui/Non),  la  date 
d'approbation  et  des  commentaires. 

3.  Évaluez  son  impact  sur  le  projet  et  sur  tous  les  projets  interdépendants  via  l'intégration 
dans  le  planning  du  Gantt 

4.  Si  cela  est  du  ressort  du  responsable  de  projet,  rejetez  ou  acceptez  la  proposition  de 
changement  (le  PMI  considère  que  c'est  toujours  au  responsable  de  projet  de  décider 
d'accepter  ou  de  rejeter  un  changement  sans  en  faire  part  aux  exécutants  lorsque  le 
projet  a  déjà  commencé....  on  comprend  avec  ce  type  de  philosophie  les  problèmes  que 
l'on  rencontre  ensuite  entre  exécutants  et  gestionnaires). 

5.  Si  cela  n'est  pas  du  ressort  du  responsable  de  projet,  référez-vous  à  la  décision  des 
instances  supérieures. 

6.  Si  les  changements  sont  validés,  n'oubliez  pas  de  refaire  signer  le  contrat  avec  toutes 
les  informations  àjourü!  C'est  certes  très  laborieux  mais  certaines  entreprises  s'en  sont 
mordus  les  doigts  de  ne  pas  l'avoir  fait  (je  parle  là  de  pertes  de  plusieurs  centaines  de 
millions  de  francs  suisses46) 

7.  N'oubliez  pas  que  le  contrat  doit  spécifier  que  les  pénalités  de  délais  ne  peuvent  avoir 
lieu  que  si  et  seulement  si  le  cahier  des  charges  initial  n'est  pas  modifiée  pendant 
l'exécution  du  projet.  Dans  le  cas  contrait,  c'est-à-dire  en  cas  de  modification  du  cahier 
des  charges,  les  délais  et  les  coûts  devront  être  mise  à  jour  et  passer  par  un  processus 
de 

La  proposition  de  changement  peut  être: 

•  Accepté  et  mise  en  œuvre  immédiatement 

•  Acceptée  sous  réserve  que  certaines  conditions  soient  satisfaites 

•  Acceptée  mais  mise  en  œuvre  plus  tard 

•  Rejetée 


Une  fois  la  décision  prise,  le  responsable  de  projet  doit: 

•  Obtenir  des  fonds  supplémentaires  (si  nécessaire) 

•  Consigner  le  résultat  dans  le  journal  de  bord  des  modifications 

•  Mettre  en  œuvre  le  changement  si  le  changement  est  accepté 

•  Mettre  à  jour  la  documentation  si  le  changement  est  accepté 


46 


Je  pense  ici  particulièrement  au  conflit  entre  l'entreprise  Bomdardier  et  les  CFF  (chemins  de  fer  fédéraux)... 
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Informer  du  changement  toutes  les  parties  intéressées 


Évidemment,  tous  les  changements  proposés  doivent  être  revus  et  leur  impact  évalué  avant 
d'être  mis  en  œuvre  ou  rejetés.  Un  projet  peut  avoir  plusieurs  niveaux  pour  la  revue  et 
l'autorisation  du  changement.  Le  PMI  insiste  sur  le  fait  que  le  responsable  de  projet  devrait 
normalement  gérer  seul  la  gestion  des  changements...  Je  nuancerai  ce  point  de  vue  en  y 
incluant  de  nombreux  "si...". 

Une  chose  intéressant  que  le  PMI  recommande  (et  moi  aussi  par  retour  d'expérience)  ce  que 
même  si  vous  avez  une  idée  qui  permette  d'améliorer  le  projet  du  client  ou  l'exécution  du 
projet,  demandez-en  toujours  l'accord  au  client!!! 

8.6.43  Le  suivi  du  temps 

Le  suivi  (gestion)  du  temps  implique  le  choix  d'une  fréquence  d'observation  et  la 
compréhension  des  différents  paramètres  d'avancement  d'un  projet. 

Commençons  par  discuter  de  la  fréquence  d'observation  ou  d'analyse  par  le  responsable  de 
projet  de  son  planning. 

Il  faut  savoir  que  dans  la  réalité,  la  complexité  et  les  possibilités  des  logiciels  de  planification 
sont  tels  qu'il  est  très  difficile  à  un  responsable  de  projet  qui  à  lui  seul  est  responsable  des  9 
rôles  du  PMBOK  de  gérer  un  projet  avec  plus  de  50  personnes  et  une  dizaine  de  fournisseurs 
heure  par  heure.  Effectivement,  cela  s'explique  par  le  fait  qu'un  suivi  correct  de  projet 
nécessite  par  ressource  suivie  de  remplir  une  dizaine  de  champs  d'informations  et  également 
de  compléter  la  documentation  annexe. 

Dès  lors  mon  retour  d'expérience  à  montré  que  l'on  peut  considérer  les  scénarios  suivants: 

•  Un  suivi  avec  une  fréquence  horaire  peut  amener  au  pire  pour  avoir  loupé  une 
information  ou  un  événement  important  à  une  déviation  positive  ou  négative  de 
quelques  jours  du  chemin  critique. 

•  Un  suivi  avec  une  fréquence  journalière  peut  amener  au  pire  pour  avoir  loupé  une 
information  ou  un  événement  important  à  une  déviation  positive  ou  négative  d'une 
semaine  du  chemin  critique. 

•  Un  suivi  avec  une  fréquence  hebdomadaire  peut  amener  au  pire  pour  avoir  loupé  une 
information  ou  un  événement  important  à  une  déviation  positive  ou  négative  d'au 
maximum  un  mois  du  chemin  critique. 

Basé  sur  ce  REX  (retour  d'expérience)  personnel  et  non  exhaustif,  le  responsable  de  projet 
peut  faire  le  cheminement  inverse:  savoir  qu'elle  est  sa  réserver  mathématique  de  temps  et 
adapter  sa  fréquence  de  suivi  en  conséquence. 

Enfin,  indiquons  que  les  responsables  de  projets  confondent  ou  ignorent  la  distinction  entre 
les  trois  concepts  du  suivi  d'avancement  du  temps  et  cette  ignorance  engendre  soit  des  graves 
problèmes  au  niveau  du  suivi  du  projet  (incompréhension  mutuelle  de  ce  qui  est  désigné  dans 
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les  courriels  ou  les  téléphones),  soit  de  la  manipulation  de  la  part  des  ressources  qui  jouent 
subtilement  avec  l'une  des  trois  informations: 


•  %  Achevé  (avancement  en  délai):  Indique  le  statut  actuel  d’une  tâche,  exprimé  en 
tant  que  pourcentage  de  la  durée  de  la  tâche.  Le  calcul  du  %  Achevé  est  lié  au  %  du 
Travail  Achevé  (voir  ci-après). 

•  %  Travail  achevé  (avancement  en  charge):  Indique  le  statut  actuel  d’une  tâche,  d’une 
ressource  ou  d'une  affectation,  exprimé  en  tant  que  pourcentage  du  travail  (effort) 
calculé  initialement  sur  la  tâche.  Le  calcul  du  %  Travail  Achevé  est  lié  au  %  Achevé. 

•  %  Physique  Effectué/Achevé  (avancement  physique):  Indique  l'avancement  réel  du 
livrable  et  ne  doit  pas  être  confondu  avec  l'avancement  en  délai  ou  en  charge  (ce  qui 
est  très  malheureusement  presque  toujours  le  cas).  Cet  indicateur  n'est  évidemment  pas 
calculable  à  partir  du  %  Achevé  ou  du  %  du  Travail  Achevé. 

source:  ©ANCORE  Managementlwww.ancoremanagement.eu 


Figure  37  Exemple  de  différence  entre  avancement  physique  et  en  délai 

Pour  un  exemple  pratique  concernant  ces  trois  indicateurs,  le  lecteur  pourra  se  référer  à  mon 
livre  électronique  sur  le  logiciel  MS  Project. 

8. 6.4.4  Le  suivi  des  coûts 


Le  suivi  des  coûts  implique  que  le  travail  d'analyse  opéré  ait  conduit  à  une  évaluation  des 
coûts  des  tâches.  Cette  évaluation  peut  être  le  fruit  d'un  calcul  tenant  compte  du  montant  des 
ressources  consommées  et  leurs  coûts  unitaires.  Elle  peut  aussi  être  le  résultat  d'une 
estimation  empirique.  Après  exécution  de  la  tâche,  il  conviendra,  dans  le  premier  cas,  de  saisir 
les  données  (quantités  et/ou  coûts  unitaires)  différentes  des  valeurs  prévues  et,  dans  le  second 
cas,  l'estimation  finale  de  la  dépense  réelle.  Ce  travail  s'ajoute  au  suivi  de  l'avancement  des 
tâches  mais  il  est  nécessaire  pour  que  le  contrôle  des  coûts  ait  un  sens.  La  conceptions  des 
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logiciels  peut  faciliter  le  travail  des  utilisateurs  ou,  au  contraire,  le  compliquer  au  point  que  le 
suivi  s'effectue  avec  retard  et  s'appuie  sur  des  données  partiellement  mises  à  jour. 

Dans  la  gestion  de  projet,  il  est  aussi  important  de  maîtriser  les  coûts  que  de  respecter  les 
échéances  et  les  performances  techniques.  Un  système  de  surveillance  doit  donc  être  mis  en 
place  que  l'on  soit  en  présence  d'un  projet  interne  ou  de  l'exécution  d'un  contrat  ou  pour  un 
tiers.  En  cas  de  contrat,  le  projet  externe  peut  être,  du  point  de  vue  du  maître  d'œuvre, 
considéré  comme  un  projet  interne.  Mais  les  conséquences  d'un  non-respect  des  objectifs  sont 
telles  que  le  maître  d'ouvrage  cherche  le  plus  souvent  à  avoir  un  droit  de  regard  sur  l'analyse 
de  l'avancement  du  projet  tant  que  du  point  de  son  exécution  que  de  ses  coûts,  en  particulier 
quand  le  contrat  prévoit  un  montant  calculé  sur  la  base  de  coûts  occasionnées  par  le  contrat, 
augmenté  d'une  commission. 

Le  système  présenté  ici  est  très  largement  adopté  un  peu  partout  dans  le  monde.  Il  adapte  au 
cas  de  la  gestion  de  projet,  les  principes  "classiques"  du  contrôle  de  gestion.  Nous  partons  de 
données  de  référence  pour  analyser  ce  qui  a  été  exécuté. 

8. 6.4.4. 1  Les  données  de  référence 

Le  budget  initial  est  celui  qui  est  défini  lors  du  lancement  du  projet,  c'est-à-dire  à  une  date  de 
début  de  projet  que  nous  désignerons  par  td  ;  il  couvre  toutes  les  charges  et  recettes 
initialement  prévues  jusqu'à  la  fin  du  projet  prévue  pour  la  date  tf  d  . 

Nous  y  ajoutons,  en  général,  une  provision  pour  imprévus  gérée  par  le  coordinateur  du  projet 
et  destinée  à  faire  face  aux  aléas  et  accidents  ;  cette  solution  d'une  "assurance  groupée"  est 
plus  judicieuse  que  celle  d'assurances  individuelles  obtenues  par  "saupoudrage"  de  la 
provision. 

Nous  définissons  alors  le  montant  initial  du  budget  initial  en  fonction  de  la  programmation 
initiale  prévisionnelle  du  projet. 

A  une  date  t  ultérieure  td  <  t  <  tf  d  ,  un  certain  nombre  d'événements  peuvent  se  produire 

faisant  que  les  prévisions  initiales  n'ont  pas  été  respectées.  Ils  peuvent  conduire  le 
coordinateur  de  projet,  en  accord  avec  sa  direction,  à  réviser  "officiellement"  certains 
objectifs  et/ou  moyens  mis  en  œuvre,  et  donc  le  budget  du  projet. 

■  à  la  date  initiale  tf  d  de  fin  de  projet,  se  substitue  la  date  révisée  tf  l  que  nous 

considérons  à  la  date  courante  t,  comme  un  objectif  techniquement  réaliste  (cette  date 
de  fin  du  projet  tft  ayant  pu  être  révisée  avant  cette  date  courant  t ) 

■  au  budget  initial,  se  substitue  le  budget  à  date  qui  intègre  les  décisions  modificatives 
intervenues  pour  tenir  compte  des  difficultés  ou  opportunités  rencontrées 

■  les  informations  disponibles  à  la  date  courante  t  peuvent  conduire  à  une  estimation  de 
coût  du  projet,  appelée  coût  prévisionnel  réestimé  à  la  date  t ,  qui  est  supérieure  (ou, 
plus  rarement,  inférieure)  à  celle  du  budget  à  date,  parce  que  des  éléments  nouveaux 
sont  intervenus  depuis  la  dernière  révision  du  budget  ou  parce  que,  lors  de  cette 
révision  il  a  été  décidé  d'être  optimiste  ou  de  mettre  sous  tension  les  équipes  pour 
contenir  les  dérives  et  les  délais. 
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8.6A4.2  Les  grandeurs  à  comparer  (CRTE,  CBTP,  CBTE...) 

Cette  analyse  s'appuie  sur  la  prévision  de  la  consommation  progressive  du  budget  à  date.  Il 
est  clair  que  la  qualité  de  ce  scénario  de  référence  conditionne  le  contrôle  de  gestion.  Nous 
examinerons  d'abord  les  grandeurs  à  comparer  avant  de  présenter  les  diagnostics  d'écart  de 
planning  et  d'écart  de  coût  que  nous  pouvons  tirer. 

Il  est  important  de  souligner  que  ces  analyses  peuvent  être  conduites  pour  le  projet  dans  son 
ensemble  mais  que  des  diagnostics  précis  et  recommandations  utiles  ne  pourront  que  se  baser 
sur  des  analyses  similaires  pour  des  ensembles  restreints  de  tâches,  ce  qui  ne  pose 
normalement  pas  de  problème  dans  la  mesure  où  les  informations  du  projet  résultent 
d'agrégations  d'informations  partielles. 

Dans  le  cadre  du  contrôle  de  projet,  l'outil  de  mesure  de  la  performance  disponible  est  la 
"valeur  acquise". 

Remarque:  La  gestion  de  la  valeur  acquise  (en  anglais,  "Earned  Value  Management",  d'où 
l'acronyme  EVM)  est  une  méthodologie  créé  aux  Etats-Unis  (norme  ANSI/EIA  Standard  748) 
dans  le  but  de  pouvoir  mesurer  les  performances  de  la  production  industrielle.  La  gestion  de  la 
valeur  acquise  a  été  concrètement  appliquée  pour  la  première  fois  par  la  United  States  Air 
Force,  au  début  des  années  1960,  pour  un  programme  militaire.  A  noter  que  le  système  se 
nommait  anciennement:  C/SCSC  pour  "Cost/Schedule  Control  System  Criteria". 

Pour  cela,  3  mesures-clés  de  performance  des  coûts  sont  fondamentales  pour  l'analyse  de  la 
valeur  acquise:  le  coût  réel  du  travail  réalisé  au  temps  t  (CRTE),  le  coût  budgétisé  du  travail 
réalisé  au  temps  t  (CBTE)  ou  le  coût  budgétisé  du  travail  planifié  (CBTP)  au  temps  t. 

D'un  point  de  vue  professionnel,  les  gestionnaires  recourent  à  l'analyse  de  la  valeur  acquise 
pour  évaluer,  lors  de  la  mise  à  jour  du  projet  à  un  moment  donné  dans  le  temps,  la 
performance,  en  termes  de  délai  et  de  coût  et  suggérer,  en  cas  d'écart  important  avec  ce  qui  a 
été  planifié,  des  actions  correctives.  C'est  donc  un  outil  utile  et  puissant  de  mesure  de  la 
performance  qui  tienne  à  la  fois  compte  des  délais  et  des  coûts,  aspects  quantitatifs  par 
excellence  du  triangle  délai,  coût,  qualité! 

Les  points  ci-dessous  sont  importants  relativement  à  l'outil  d'audit  de  MS  Project  tel  que 
présenté  dans  mon  e-book  sur  le  sujet! 

A  la  date  courante  t,  un  ensemble  de  tâches  a  été  en  totalité  ou  en  partie  achevé,  ce  qui  se 
traduit  par  un  coût  encouru  ou  Coût  Réel  du  Travail  Effectué  -  CRTE  correspondant  au  coût 
réel  des  travaux  réalisés  à  la  date  d'état  t  et  imputables  au  projet. 

Si  nous  avions  travaillé  en  conformité  avec  le  budget  initial,  les  travaux  qui  auraient  dû  être 
réalisés  à  la  date  d’état  t  auraient  normalement  conduit  à  supporter  un  Coût  Budgété  du 
Travail  Prévu  -  CBTP  (appelé  encore  budget  encouru). 

La  différence  observée  à  la  date  t  entre  ce  qui  a  été  prévu  (budget  encouru)  et  ce  qui  est  réalisé 
(coût  encouru)  a  deux  origines  possibles: 

■  un  effet  quantité,  c'est-à-dire  des  écarts  de  planning  (travail  physique  en  avance  ou  en 
retard  par  rapport  aux  prévisions) 
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■  un  effet  prix,  c'est-à-dire  des  écarts  sur  les  valeurs  des  facteurs  consommées  qui  sont 
imputables  à: 

o  des  différences  quantitatives  utilisées  (amélioration  ou  dégradation  de 
productivité) 

o  et  des  différences  de  prix  unitaires  valorisant  ces  quantités  (prix  supérieurs  ou 
inférieur  par  rapport  aux  prévisions). 

L'idée  suivie  consiste  à  comparer  respectivement  ce  qui  était  prévu  (CBTP)  et  ce  qui  est 
réalisé  (CRTE)  à  la  date  d'état  à  une  troisième  grandeur  correspondante  à  une  valeur  théorique 
de  travaux  exécutés  qui  doit  être: 

■  comparable  au  coût  encouru  (CRTE),  parce  qu'elle  adopte  la  même  hypothèse 
d'avancement  au  planning : 

1.  Au  niveau  du  projet:  mêmes  tâches  achevées  ou  en  cours 

2.  Au  niveau  d'une  tâche:  avancement  identique  en  % 

■  et  comparable  au  budget  encouru  (CBTP),  parce  qu'elle  adopte  la  même  hypothèse  de 
valeurs  de  ressources  consommées  (absence  totale  de  dérive  de  coût  pour  les  tâches 
achevées  ou  en  cours) 

Dès  lors,  cette  valeur  théorique  de  travaux  exécutés  que  l'on  appelle  Coût  Budgété  du  Travail 
Effectué  -  CBTE  (ou  valeur  budgétaire  du  réalisé  ou  encore  valeur  acquise )  s'obtient  tout 
simplement  en  valorisant  les  tâches  effectuées  par  leurs  coûts  prévisionnels  (Budget  At 
Completion  -  BAC)  définis  dans  le  budget  à  date  (on  parle  alors  de  valorisation  à  prix 
budget).  Cette  démarche  n'est  que  la  transposition  d'une  démarche  classique  dans  les  analyses 
d'écart  en  contrôle  de  gestion. 

Voici  les  équivalences  anglophones  de  ces  premiers  facteurs: 

CRTE  ACWP 
CBTP  BCWS 
CBTE  BCWP 


et  leur  affichage  dans  MS  Project: 
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Attention!!!  Suivant  la  taille  des  valeurs,  la  fenêtre  Earned  Value  ci-dessus  n'arrive  pas  à 
afficher  les  résultats  de  calculs.  Dans  ce  cas,  passez  par  la  table  Cost  disponible  dans 
MS  Project  ou  créez  votre  propre  formulaire. 


8.6.4.43  Écart  de  planning  (SV) 

La  comparaison  du  CBTE  au  CBTP  porte  sur  des  consommations  de  budget  valorisées  aux 
mêmes  coûts  d'utilisation  de  ressources.  Toute  distorsion  introduite  par  des  coûts  différents 
entre  ces  deux  grandeurs  est  donc  éliminée.  La  différence  entre  ces  deux  grandeurs 
correspond  donc  uniquement  à  une  différence  de  planning,  d'où  son  appellation  d'écart  de 
planning  SV  ( schedule  variance )  que  nous  définissons  simplement  par: 

SV  =  CBTE  -  CBTP  =  BCWP  -  BCWS 

L'analyse  de  ces  informations  est  simple: 

■  Si  le  CBTE  est  supérieur  au  CBTP  (SV  positif),  les  réalisations  du  projet  sont  en 
avance  par  rapport  aux  prévisions,  et  ce  "globalement"  (il  convient,  en  effet,  d'analyser 
plus  en  détail  le  planning  pour  vérifier  si  certaines  tâches  critiques  n'ont  pas  pris  de 
retard,  ce  que  ne  permet  pas  de  déceler  l'indicateur  synthétique  proposé) 

■  Si  le  CBTE  est  inférieur  au  CBTP  (SV  négatif),  les  réalisations  sont  "globalement"  en 
retard  par  rapport  aux  prévisions. 

L'écart  de  planning  SV  est  un  indicateur  exprimé  en  valeur  ;  son  signe  permet  d'indiquer  si 
nous  sommes  en  avance  ou  en  retard,  mais  difficilement  d'en  apprécier  l'importance.  L'usage 
complémentaire  d'un  indicateur  en  valeur  relative  permet  de  mieux  apprécier  l'importance  du 
retard  ou  de  l'avance  diagnostiqué.  Il  suffit,  de  diviser  l'écart  de  planning  SV  par  le  CBTP: 

sv%  -  —  -  CBTE  ~  CBTP  -  BCWP  ~  BCWS 

CBTP  ~  CBTP  ~  BCWS 


8.6.4.4.4  Écart  de  coût  (CV) 

Le  CRTE  et  le  CBTE  ont  en  commun  la  même  hypothèse  d'avancement  des  travaux.  Ces 
grandeurs  devraient  donc  être  identiques  si  pour  chaque  tâche  achevée  ou  en  cours,  le  coût 
réel  coïncidait  avec  le  coût  prévu.  Bien  évidemment,  il  n'en  est  rien  et  nous  observons  un 
écart  de  coût  CV  ( cost  variance)  comme: 

CV  =  CBTE  -  CRTE  =  BCWP  -  ACWP 

Cette  différence  a  pour  origine  des  variations  de  coût  de  réalisation  des  tâches.  La  variation  de 
coût  de  réalisation  d'une  tâche  s'explique: 

■  par  des  variations  de  consommations  de  ressources  utilisées  (variation  du  travail 
requis,  variation  des  pertes  de  matières,  . . .) 

■  et  des  variations  de  coût  de  ressources  (variation  de  l'importance  relative  des  heures 
supplémentaires,  variation  de  conditions  d'achet  de  matières,  changement  de  sous- 
traitance,...) 
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Remarque:  Le  résultat  de  ces  variations  est  imputable  à  une  amélioration  ou  une  dégradation 
de  performances  techniques,  organisationnelles  et  de  gestion  que  les  acteurs  du  projet 
maîtrisent  en  grande  partie,  Cette  appellation  d'écart  de  coût  est  d'une  certaine  façon 
trompeuse  et  traduit  mal  l'interprétation  qu'il  convient  d'en  donner.  Aussi  utilise-t-on  plus 
volontiers  d'autres  appellations  comme  écart  de  performance  ou  encore  écart  de  productivité. 

L'analyse  de  ces  informations  est  simple: 

■  Si  le  coût  budgété  du  travail  effectué  CBTE  est  inférieur  au  coût  réel  du  travail 
effectué  CRTE  (écart  de  coût  CV  négatif),  nous  sommes  en  présence  de  dépenses 
supplémentaires  qu'il  faudra  compenser  par  des  économies  ultérieures  ou,  à  défaut,  par 
une  augmentation  de  budget  ;  nous  sommes  donc  en  présence  d'un  risque  de 
dépassement  budgétaire 

■  Si  le  coût  budgété  du  travail  effectué  CBTE  est  supérieur  au  coût  réel  du  travail 
effectué  (écart  de  coût  CV  positif),  les  réalisations  du  projet  ont  coûté  moins  cher  que 
prévu,  ce  qui  accroît  les  chances  de  tenir  dans  l'enveloppe  budgétaire  initiale. 

L'indicateur  de  l'écart  de  coût  CV  mesure  la  dérive  budgétaire  (positive  ou  négative)  ;  on 
complète  généralement  cette  information  par  un  indicateur  en  valeur  relative  qui  permet  de 
mieux  apprécier  l'importance  de  l'enjeu  par  rapport  au  projet.  Il  suffit,  de  diviser  l'écart  de 
coût  par  la  valeur  budgétaire  du  réalisé  (qui  constitue  la  référence  en  matière  de  dépenses), 
pour  obtenir  l'écart  de  coût  relatif  que  nous  appellerons  encore  écart  de  performance  relatif  : 

cv%  -  —  -  CBTE  ~  CRTE  -  BCWP~ACWP 

CBTE  ~  CBTE  ~  BCWP 

Tous  les  indicateurs  vus  jusqu'à  maintenant  peuvent  se  résumer  avec  le  graphique  fameux  de 
la  courbe  en  S  (sigmoïde)  suivant47: 


47 


La  courbe  est  en  S  car  la  phase  exécution  du  projet  est  celle  qui  est  censée  être  la  plus  gourmande  en  coûts. 
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Évidemment,  comme  l’indique  le  PMBOK,  il  est  possible  de  faire  usage  de  modèles 
mathématiques  pour  projeter  la  courbe  du  AC  WP  afin  de  déterminer  le  ECP  (Estimate  to 
Complété).  Ainsi,  on  fera  usage  de  la  régression  non  linéaire  (Gauss-Newton),  des  modèles  de 
lissages  exponentiels  (EWSM,  Holt’s)  ou  ARMA  (Autoregressive  Moving  Average)  ou 
encore  des  réseaux  de  neurones. 


Nous  verrons  quelques  exemples  de  ces  calculs  à  la  fin  du  présent  livre. 

8.6A4.5  Indices  de  performances 

Il  existe  aussi  des  indicateurs  de  performances  très  souvent  utilisés  en  gestion  de  projets. 
Nous  avons  ainsi  le  IPC  (CPI  en  anglais)  qui  est  l 'indice  de  performance  des  coûts  et  qui  est 
défini  par  la  relation: 


IPC  -  CBTE  -  BCWP 
~  CRTE  ~  ACWP 

ainsi  que  le  IPP  (SPI  en  anglais)  qui  est  l'indice  de  performance  de  la  planification  et  qui  est 
défini  par: 


_  CBTE  _  BCWP 
~  CBTP  ~  BCWS 

et  enfin  le  TCPI  qui  est  l'indice  de  performance  à  accomplir  (To  Complété  Performance 
Index)  défini  par  le  rapport  entre  le  coût  du  travail  restant  à  effectuer  planifié  (toujours 
positif)  et  les  fonds  restants  à  dépenser,  à  la  date  d'état,  ou  le  budget  à  l'achèvement  (pouvant 
être  négatif  ou  positif): 
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Une  valeur  TCPI  supérieur  à  1  indique  un  besoin  de  performances  accru  pour  le  travail  restant 
sur  le  projet  afin  de  respecter  le  budget  (vous  devez  peut-être  sacrifier  la  qualité).  Moins  de  1 
indique  que  les  performances  peuvent  être  réduites  pour  respecter  le  budget,  ce  qui  permet 
d'augmenter  la  qualité  ou  le  profit. 

Remarques: 

■  Pour  un  indicateur  de  coûts  de  type  variations  (VC  ou  SV),  la  valeur  peut-être  positive 
ou  négative  comme  nous  le  verrons  plus  loin  dans  les  exemples.  Une  variation  positive 
indique  l'avance  sur  les  prévisions,  ce  qui  signifie  que  le  budget  établi  ne  sera  pas 
dépassé.  Une  variation  négative  signale  du  retard  sur  les  prévisions  ou  un  dépassement 
du  budget  (des  mesures  s'imposent  donc!). 

■  Pour  les  indicateurs  d'audit  de  type  ratios,  comme  l'indice  de  performance  des  coûts 
(. IPC)  ou  l'indice  de  performance  ( IP P ),  la  valeur  peut  être  supérieure  ou  inférieure  à 
1.  Une  valeur  supérieure  à  1  indique  de  l'avance  sur  les  prévisions  ©.  Une  valeur 
inférieure  à  1  indique  du  retard  sur  les  prévisions  ©,  ou  un  dépassement  du  budget. 

Par  exemple,  un  IPP  de  1.5  signifie  que  vous  avez  "consommé"  seulement  67% 

(1/1.5)  du  temps  prévu  pour  réaliser  une  partie  d'une  tâche  sur  une  période  donnée.  Un 
IPC  de  0.8  (1/0.8-1)  indique  que  vous  avez  dépensé  25%  de  temps  supplémentaire 
pour  une  tâche  par  rapport  à  ce  qui  était  planifié 

Attention!  Prenez  garde  au  fait  que  les  calculs  se  font  aussi  en  fonction  de  l'option  de  calcul 
de  MS  Project  ci-dessous  ( Tools/Options/Calculation ). 

Voyons  deux  cas  pratiques  simplifiés  à  l'extrême  pour  assimiler  les  concepts.  Bien 
évidemment,  plus  tard  nous  appliquerons  cela  à  un  vrai  projet  (qui  sera  de  petite  taille 
mais  qui  est  vrai  quand  même. . .). 

8.6A4.6  Les  grecques 

Il  est  de  plus  en  plus  courant  d'appliquer  des  techniques  du  domaine  des  statistiques  à  la 
gestion  de  projets  pour  rendre  le  domaine  moins  empirique  et  plus  scientifique. 

On  trouve  de  tout...  du  pire  et  du  meilleur...  un  exemple  fréquent  dans  le  domaine  de 
l'informatique  est  de  faire  des  extrapolations  linéaires  (régression  linéaire)  des  charges  du 
travail: 
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c'est  un  peu  simpliste  et  entaché  d'une  incertitude  non  quantifiée...  (on  se  retrouve  donc  au 
18eme  siècle  scientifiquement  parlant). 

Le  mieux  est  de  commencer  par  la  base  en  faisant  usage  d'indicateurs  indépendants  du  profil 
de  la  charge  du  travail  réalisé. 

On  peut  ainsi  s'inspirer  quelques-uns  des  indicateurs  du  modèle  de  pricing  d'option  de 
Black  &  Scholes  (l'inspiration  se  situe  uniquement  au  niveau  des  noms  et  de  la  notation...). 

Ainsi,  nous  avons: 


-  Le  "delta"  défini  par: 


A  = 


8R 

ôt 


qui  donne  la  variation  instantanée  du  Retard  (R)  du  physique  réalisée  en  fonction  de  la 
variation  du  temps  d'avancement  des  tâches  sous-jacentes.  Par  exemple,  si  un  projet 
comportement  plusieurs  tâches  a  une  variation  de  retard  de  2  heures  sur  l'avancement  du 
physique  réalisé  par  rapport  au  planifié  qui  était  de  10  heures  d'efforts,  le  delta  vaudra  (sous 
forme  discrète): 


A  = 


A R 
A  t 


—  =  20% 
10 


ce  qui  inaugure  rien  de  bon  puisque  cela  indique  un  taux  de  retard  de  20%  à  l'heure...  On  peut 
aussi  tracer,  sans  utiliser  le  delta,  une  courbe  représentant  le  retard  en  fonction  de 
l'avancement  du  projet.  C'est  une  information  pertinente  qui  permet  en  utilisant  des  techniques 
de  régression,  plus  poussées  que  la  régression  linéaire,  de  prendre  les  dispositions  ad  hoc 
avant  que  cela  ne  soit  trop  tard. 


-  Le  "thêta"  défini  par: 
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0  = 


dF 

dt 


qui  donne  la  variation  instantanée  du  retard  de  la  date  de  fin  du  projet  (F)  en  fonction  de  la 
variation  du  temps  d'avancement  des  tâches  sous-jacentes.  Par  exemple,  si  un  projet 
comportant  plusieurs  tâches  pour  une  durée  totale  de  2  ans  a  un  de  retard  de  3  heures  sur  la 
date  de  fin  du  projet  par  rapport  au  planifié  après  8  heures  de  temps  écoulé,  le  thêta  vaudra 
(sous  forme  discrète): 


-  =  37.5% 
8 


donc  le  projet  subit  37.5%  d'unité  de  temps  de  retard  sur  la  date  de  fin  par  unité  de  temps 
écoulée  sur  le  chemin  critique.  On  peut  aussi  tracer,  sans  utiliser  le  thêta,  une  courbe 
représentant  le  retard  sur  la  date  de  fin  en  fonction  de  l'avancement  du  projet.  C'est  une 
information  pertinente  qui  permet  en  utilisant  des  techniques  de  régression,  plus  poussées  que 
la  régression  linéaire,  de  prendre  les  dispositions  ad  hoc  avant  que  cela  ne  soit  trop  tard. 

-  Le  "rhô"  défini  par: 


qui  donne  la  variation  instantanée  du  coût  du  projet  (C)  consommé  (par  rapport  au  planifié)  en 
fonction  de  la  variation  du  temps  d'avancement  des  tâches  sous-jacentes. 

-  Le  "véga"  défini  par: 


_  ÔC_ 
do 


qui  donne  la  variation  instantanée  du  coût  du  projet  (C)  consommé  (par  rapport  au  planifié)  en 
fonction  de  la  variation  l'écart-type  (volatilité)  de  la  variation  des  coûts  des  tâches  sous- 
jacentes.  L'écart-type  se  calcule  traditionnellement  en  %. 
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Exercice: 


Dans  MS  Project,  créez  une  tâche  Tl  de  500.-  (francs)  en  coût  fixe  et  d'une  durée  5  j  (à  8 
h./jour)  commençant  un  lundi  à  8h00  et  finissant  donc  le  vendredi  de  la  même  semaine  à 
17h00  (vous  pouvez  très  bien  imaginer  que  cette  tâche  représente  l'ensemble  d'un  lot  de 
tâches). 

El.  Enregistrez  la  baseline  (planification  initiale)  et  ensuite  doublez  la  durée  ET  le  coût  de  la 
tâche. 

Question  1  :  quelle  est  la  valeur  du  BAC  et  du  FAC  ainsi  que  leur  différence?  Que  représente 
le  signe  de  cette  différence  (VAC:  Variance  At  Completion)? 

Question  2:  quelle  est  la  valeur  du  BCWS  (budget  encouru/CBTP)  au  premier,  troisième, 
sixième  et  neuvième  jour  de  la  tâche  (à  17h00  pour  chaque  jour). 

Question  3:  la  valeur  du  BCWS  (budget  encouru/CBTP)  correspond-elle  à  sa  définition.  Si 
oui,  pourquoi? 

Question  4:  si  nous  mettons  la  tâche  effectuée  à  30%,  les  valeurs  du  BCWS  au  premier, 
troisième,  sixième  et  neuvième  jour  de  la  tâche  (à  17h00  pour  chaque  jour)  changent-t-elles 
par  rapport  au  moment  où  nous  avions  0%  d'effectué? 

Question  5:  affichez  le  Tracking  Gantt  (Gantt  Suivi)  pour  comparer  la  baseline  à  la 
planification  actuelle. 

E2.  Mettez  maintenant  la  date  d'état  du  projet  (status  date)  à  la  fin  du  sixième  jour  ouvrable 
(soit  le  deuxième  lundi  à  17h00),  les  coûts  fixes  à  500.-  et  le  travail  accompli  à  75%. 

Question  1:  Quelle  est  la  valeur  de  AC  WP  (coût  encouru/CRTE)?  La  valeur  obtenue 
correspond-elle  au  coût  réel  des  travaux  réalisés  à  la  date  d'état  et  imputable  au  projet  (selon 
définition). 

Question  2.  Quelle  est  la  valeur  du  coût  budgété  du  travail  effectué  BCWP  (CBTE)? 
Correspond-il  à  la  relation  (selon  la  définition)  suivante: 

BCWP  =  BAC  •  %Complete  =  500  •  75% 

ou  à  celle  avec  le  %  à  la  date  d'état: 

BCWP  =  BAC  ■  %Complete  =  500  •  60%  ? 

Mettez  ensuite  le  coût  fixe  de  la  tâche  courante  Tl  à  2000.-  et  dites  combien  vaut  le  BCWS, 
BCWP  et  ACWP. 

Question  3:  Calculer  les  valeurs  de  l'écart  de  planning  SV  et  de  l'écart  de  coût  CV  et  des 
indicateurs  SV%  et  CV%?  Comment  interpréter  les  signes  positifs  ou  négatifs  des  résultats 
obtenus.  Quelle  est  la  valeur  du  FAC? 

Question  4:  Quelles  sont  les  valeurs  du  CPI  (IPC),  IPP  (SPI)  et  TCIP  (TCPI). 
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E3.Vous  avez  planifié  un  projet  pour  développer  un  logiciel  qui  devrait  prendre  1  an.  Le  coût 
total  de  ce  projet  est  budgété  à  12'500.-  par  mois. 

Six  mois  après  le  début  du  projet,  nous  constatons  que  le  travail  est  effectué  à  50%  et  que 
nous  avons  dépensé  70'000.-.  Sur  la  base  de  ces  informations,  remplissez  le  tableau  ci- 
dessous: 


Valeurs 

BAC 

=12*1 2'500=  1 50'00 

PV 

=50%*150'000=75'000.- 

EV 

=50%*150'000=75'000.- 

AC 

=70'000.- 

CV 

=E  V  -  AC=7  5  ’000-70'000=5 '000.  - 

SV 

=E  V -P  V =7  5  '000-7 5 '000=0 .  - 

CPI 

=EV/AC=75'000/70'000=1 .07 

SPI 

=EV/PV =7  5  '000/7 5 '000=  1 

EAC 

=B  AC/CPI=  1 50'000/l  .07= 140'1 86.9 1 .  - 

ETC 

=EAC-AC=  140T  86.9 1-70'000=70'1 86.91.- 

VAC 

=BAC-EAC= 1 50’000- 140'  186.91  =9’8 1 30.9 

Ainsi,  le  projet  n'est  ni  en  avance  ni  en  retard  comme  le  montre  le  SPI  de  1  (s'il  avait  été  plus 
petit  que  1  le  projet  aurait  été  en  retard,  plus  grand  que  1  en  avance). 

Sinon  le  projet  aura  un  coût  final  probablement  inférieur  à  ce  qui  avait  été  prévu  étant  donné 
que  le  CPI  est  supérieur  à  1 . 
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Solutions: 

Exercice  1: 

Réponse  1:  Le  BAC  vaut  bien  évidemment  500.-  le  FAC  quant  à  lui  pour  des  raisons  évidents 
vaut  1000.-.  La  différence  est  de  -500.-.  La  variation  est  négative  car  elle  représente  une 
augmentation  des  coûts  (ce  qui  est  négatif  pour  le  coordinateur  de  projet. . .) 

Réponse  2:  Le  BCWS/CBTP  (Budgeted  Cost  Work  Sheduled)  est  donné  selon  la  date  d'état 
seulement  (d'où  le  "Scheduled").  Nous  avons  donc: 

Nous  avons  donc: 

-  Au  premier  jour  à  17h00:  100.-  (le  1/5  de  500.-  selon  le  budget) 

-  Au  troisième  jour  à  17h00:  300.-  (les  3/5  de  500.-  selon  le  budget) 

-  Au  sixième  jour  à  17h00:  500.-  (les  5/5  de  500.-  selon  le  budget) 

-  Au  neuvième  jour  à  17h00:  500.-  (toujours  les  5/5  de  500.-  selon  le  budget) 

Réponse  3:  Oui  les  valeurs  données  du  BCWS/CBTP  correspondent  bien  à  sa  définition  car  il 
indique  bien  les  coûts  sur  la  base  de  la  planification  initiale  et  non  sur  la  courante  relativement 
à  la  date  d'état.  Pour  preuve,  à  partir  du  5eme  jour,  nous  avons  toujours  BCWS=500.-  même  si 
la  tâche  courante  est  maintenant  de  10  jours  (en  d'autres  termes,  si  nous  mettons  la  date  d'état 
au  8eme  jour,  le  BCWS  vaudra  toujours  500.-)! 

Réponse  4:  Non  les  valeurs  du  BCWS/CBTP  ne  changent  aucunement  car  elles  ne  dépendent 
pas  tu  travail  effectué  par  définition  mais  de  l'analyse  qu'en  fait  le  coordinateur  de  projet 
comme  si  le  travail  avait  été  fait  jusqu'à  la  date  d'état  (parfaitement  selon  la  planification 
initiale). 

Réponse  5:  La  tâche  telle  que  préparée  avec  sa  planification  initiale  est  représentée  dans  MS 
Project  par: 


O 

TaskName 

Fixed  Ce  T  | 

Duratk  T  j 

24  Oct  '05 

31  Oct  '05  i 

S 

M  T  W  T  F  S  S 

M  T  W  T  F  ! 

s  |  s  r 

Tl 

SFr.  500.00 

1 0  days 

. . . . 

0% 

Exercice  2: 

Réponse  1:  La  valeur  de  l'ACWP  (coût  encouru/CRTE)  est  de  300.-  La  réponse  est  donc 
"Oui"  car  sur  la  base  des  10  jours  de  la  tâche  selon  la  planification  courante,  nous  avons  bien: 


ACWP  =  CRTE  =  -6  j.  =  500  •  60%  =  300.  - 

10;. 

la  valeur  obtenue  correspond  bien  au  coût  réel  des  travaux  réalisés  et  imputable  au  projet  et 
ceci  à  la  date  d'état  (car  dans  notre  exemple  elle  est  antérieure  au  travail  effectué!  ! !)  et 
correspondant  à  un  travail  effectué  à  60%. 
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Si  le  %  Achevé  était  avant  la  date  d'état,  l’AC  WP  indiquerait  le  coût  réel  à  la  date  STOP  de 
MS  Project  correspondante. 

Réponse  2:  le  BCWP  (Budgeted  Cost  Work  Performed)  correspond  forcément  à: 

BCWP  =  CBTE  =  BAC  ■  %Complete  (à  date  d'état)  =  500  •  60%  =  300 

Effectivement,  nous  avons  changé  la  durée  de  la  tâche  et  non  ses  coûts  par  rapport  à  la 
planification  initiale.  Donc  nous  devons  avoir  une  variation  nulle  des  coûts  (CV)  tel  que: 

CV  =  CRTE  -  CBTE  =  ACWP  -  BCWP  =  300  -  300  =  0 

et  comme  nous  avons  ACWP  =  300.-  cela  répond  à  la  question.  Le  BCWP  correspond  donc 
bien  aux  coûts  initiaux  de  la  tâche  (500)  rapporté  à  la  durée  de  10  jours  relativement  à  la 
position  de  la  date  d'état  (60%) 

Si  nous  changeons  les  coûts  fixes  de  la  tâche  à  2000.-,  nous  avons  en  toute  logique  (toujours 
selon  la  date  d'état!): 


ACWP  =  CRTE  =  2000  •  60%  =  l'200.  - 

BCWS  =CBTP  =  500.-) 

)  ne  changent  pas  par  rapport  à  avant  ! 

BCWP  =  CBTE  =  300.  - 


Réponse  3:  Nous  avons  alors  pour  les  indicateurs  d'écart  de  planning  et  de  coût,  selon  les 
définitions  (avec  la  tâche  à  2000.-): 


SV  =  CBTE  -  CBTP  =  BCWP  -  BCWS  =  300  -  500  =  -200 


300-500 

sv%  = - =  -40% 

500 


Le  résultat  étant  négatif,  cela  signifie  que  la  dépense  des  coûts  (et  donc  le  travail)  à  un  retard 
de  200.-  selon  la  planification  initiale  (d'où  le  fait  que  nous  parlions  de  Schedule  Variance), 
soit  une  variation  de  -40%  (le  40%  de  500  étant  égal  à  200)  par  rapport  à  ce  qui  était  prévu 
(retard)  à  cause  du  fait  que  notre  tâche  est  passée  de  5  à  10  jours! 


Nous  avons  pour  l'écart  des  coûts: 


CV  =  BCWP  -  ACWP  =  CBTE  -  CRTE  =  300  - 1200  =  -900 


CV%  =  —  1200  =  -300% 
300 


Nous  avons  donc  une  variation  de  -900.-  (en  plus  les  coûts  ont  augmenté!)  à  travail  égal  et 
durée  égale  entre  la  tâche  dans  planification  initiale  (tirée  à  10  jours)  et  la  tâche  courante.  Cela 
correspond  à  un  écart  de  300%  (le  300%  de  300  étant  900). 

La  valeur  du  PAC  est  de  toute  évidence  de  2'000.- 


Réponse  4:  Les  valeurs  des  indicateurs  de  performance  sont  respectivement: 
-  Indicateur  de  performance  des  coûts: 
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CPI  = 


BCWP  CBTE  300 


ACWP  CRTE  1200 


=  0.25 


cette  valeur  est  mauvaise.  Nous  avons  un  rapport  de  4  (l'inverse  de  0.25)  entre  ce  que  la  tâche 
nous  coûte  en  réel  à  la  date  d'état  et  ce  qu'il  nous  aurait  coûté  selon  le  même  avancement  à  la 
planification. 

Plus  on  est  proche  de  1  plus  les  coûts  sont  respectueux  de  la  planification  (au-dessus  de  1  on 
économise  même  de  l'argent!).  La  valeur  tend  vers  zéro  dans  le  cas  contraire.  Le  résultat  est 
donc  ici  assez  médiocre. 


-  Indice  de  performance  de  la  planification  et  qui  est  défini  par: 

_  BCWP  _  CBTE  _  300  _ 

~  BCWS  ~  CBTP  ~  500  ~ 


cet  indicateur  s'interprète  de  la  manière  suivante  dans  notre  exemple:  à  la  date  d'état  nous 
avons  60%  du  travail  par  rapport  à  la  tâche  initiale  à  coût  égal.  Le  rapport  tend  vers  1  au  fur  et 
à  mesure  (dans  notre  exemple!)  que  la  date  d'état  tend  vers  le  10eme  jour  de  la  tâche  actuelle. 
Tant  que  la  date  d'état  est  inférieure  à  cinq  jours  précédant  le  début  de  la  tâche  le  rapport  vaut 
toujours  0.5  (puisque  la  durée  a  doublé,  nous  avions  50%). 

Dans  tous  les  cas,  une  valeur  inférieur  à  1  indique  un  retard  dans  le  travail  à  coût  égal,  une 
valeur  supérieure  à  1  un  avancement. 

-  Indice  de  performance  à  accomplir: 


tcpi  =  bac-cbte 

BAC  -  CRTE 


BAC  -  BCWP 
BAC  -  ACWP 


500-300 

500-1200 


200 

-700 


-0.29 


le  TCPI  (To  Complété  Performance  Index)  nous  indique  s'il  est  négatif  que  nous  avons 
dépassé  la  date  d'état  à  partir  du  moment  auquel  la  valeur  travail  restant  à  accomplir  dépasse 
ce  qui  avait  été  initialement  budgété.  Au  moment  où  la  date  de  dépassement  a  lieu,  le  TCPI 
est  infini  (singularité). 

Pendant  qu'il  est  négatif  le  coordinateur  de  projet  doit  chercher  à  diminuer  les  coûts  afin  de 
revenir  dans  les  positifs  (diminution  de  la  qualité  de  la  prestation)  ou  à  diminuer  la  durée  en 
gardant  les  coûts  (heures  supplémentaires  en  perspective  quoi!).  Il  peut  bien  évidemment 
jouer  soigneusement  sur  les  deux  tableaux:  coûts  et  durée! 

8. 6.4.5  Tests 


Dans  le  cadre  de  la  réalisation  de  projets  il  y  aura  presque  toujours  des  phases  de  test  (par 
exemple  en  informatique  on  parle  de  version  alpha,  betal,  beta2,  . . .,  RTM)  qui  précédent  la 
mise  en  production  ou  la  livraison  du  produit. 

Le  domaine  du  test  est  extrêmement  vaste  selon  les  métiers.  Citons  juste  quelques  exemples: 

•  Informatique:  Tests  manuels  ou  automatiques  en  labo  ou  "salle  blanche"  pour  des 
serveurs,  tests  avec  key  users  pour  des  logiciels  clients  en  utilisant  les  techniques 
statistiques  de  l'AMDEC  et  Six  Sigma  comme  indicateurs  de  fiabilité  (voir  mon  livre 
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de  mathématique  appliquée  sur  ces  deux  sujets).  Mise  en  situation  réelle  avec  des 
"Stress-Test"  (analyse  de  la  robustesse) 

•  Pharmaceutique:  Tests  de  rémission  ou  de  survie  sur  des  cohortes  (panels)  en  utilisant 
les  tests  non  paramétriques  de  Kaplan-Meier  (voir  mon  livre  de  mathématique 
appliquée  sur  ce  sujet). 

•  Mécanique/Électronique:  Bancs  d'essais  et  étude  de  vieillissement  accéléré  en  utilisant 
les  techniques  statistiques  de  l'AMDEC  (voir  mon  livre  de  mathématique  appliquée 
sur  ce  sujet).  Mise  en  situation  réelle  avec  des  "Stress-Test"  (tests/analyse  de  la 
robustesse) 

•  Administration/Finance:  "Stress-Test"  (analyse  de  la  robustesse  en  situation  de  crise) 
ou  mise  en  place  de  l'étude  statistique  Six  Sigma  des  processus  avec  l'indicateur  RTY 
(voir  mon  livre  de  mathématique  appliquée  sur  ce  sujet). 

•  Plans  d'expériences:  Vérifier  le  comportement  du  produit  ou  déterminer  les  conditions 
de  fonctionnement  optimales  en  utilisant  les  plans  de  criblage  (Fisher),  de  Taguchi,  de 
Hadamard,  etc.  (voir  mon  livre  sur  le  sujet  pour  plus  de  détails). 

8. 6.4.6  Gestion  de  la  qualité 

“La  qualité  est  l'ensemble  des  propriétés  et  caractéristiques  d'un  produit  ou  service  qui  lui 
confèrent  l'aptitude  à  satisfaire  des  besoins  exprimés  (conformités/exigences)  ou  implicites 
(légaux/réglementaires)  lors  de  sa  réalisation  et  lors  de  son  utilisation  et  à  réduire  les  coûts 
par  la  réduction  des  dysfonctionnements  et  par  la  même  de  garantir  une  régularité  de 
fonctionnement 

Avant  de  commencer,  signalons  au  lecteur  que  la  qualité  (comme  tout  le  reste  des  sujets  du 
présent  support),  est  un  métier  dont  tous  les  détails  tiendraient  dans  un  ouvrage  d'environ 
l'500  pages  A4.  Il  va  de  soi  que  ce  qui  va  suivre  n'est  donc  pas  exhaustif.  Le  lecteur  intéressé 
cependant  à  l'approche  méthodologique  pourra  se  référer  au  magnifique  ouvrage  Management 
de  la  qualité  de  Frédéric  CANARD  (éditions  Gualino/lextenso;ISBN  978-2297011112)  et 
pour  la  partie  quantitative  (héritages  de  Deming,  Shewhart,  Taylor  et  cie...)  à  mon  livre  sur  les 
Mathématiques  Appliquées. 

La  qualité  est  considérée  comme  un  facteur  de  compétitivité  et  de  différenciation  si  tant  est 
que  le  temps  passé  et  les  coûts  inhérents  à  l'atteinte  de  ce  niveau  de  qualité  soient  justifiés  en 
termes  de  rentabilité  et  de  positionnement  tarifaire!!!  Effectivement,  il  est  très  logiquement 
difficile  de  garantir  un  niveau  de  qualité  élevé  qui  soit  répétable  et  prédictible  sans  y  voir  en 
filigrane  une  augmentation  des  prix  et  ce  surtout  si  les  systèmes  de  travail  et  de  contrôle  ne 
sont  pas  automatisés  au  maximum.  Effectivement,  il  y  a  environ  20  ans,  un  niveau  de  contrôle 
élevé  impliquait  l'intervention  d'experts  ultra  qualifiés  avec  des  doctorats  en  statistiques  et  de 
facto  rémunérés  à  hauteur  de  leur  expertise. 

Cependant  il  existe  à  notre  époque  presque  tous  les  moyens  automatisés  (solutions  logicielles, 
matérielles)  pour  réduire  drastiquement  les  coûts  de  contrôle  qualité  et  ainsi  dégager  du  temps 
pour  développer  de  nouveaux  services  à  forte  valeur  ajoutée  et  à  forte  marge  et  sans  avoir 
besoin  d'individus  qualifiés. 
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Nous  avons  vu  dans  le  modèle  MS  Word  de  cahier  des  charges  donné  pendant  le  cours  qu'il  y 
avait  un  point  concernant  la  qualité  qui  consistait  donc  à  identifier  des  critères  quantifiables 
de  la  qualité  de  la  réalisation  du  projet  ainsi  que  du  livrable  et  de  l'utilisation  de  celui-ci 
pendant  sa  durée  de  vie  (échantillonnage,  fiabilité,  tolérancement,  etc.).  Nous  avons  aussi  vu 
que  dans  ce  même  cahier  des  charges  il  était  important  de  définir  le  Plan  d 'Assurance 
Qualité48  (PAQ)  ainsi  que  la  Charte  des  Normes  et  Standards  (CNS)  qui  contiennent  donc 
la  liste  des  normes  et  standards  nationaux  et  internationaux  à  respecter  dans  le  cadre  du  projet 
et  les  moyens  de  mesure  scientifiques  de  respect  des  critères  qualité. 

La  stratégie  qualité  dans  le  cadre  d'un  projet  peut  ainsi  se  résumer  de  manière  un  peu  simpliste 
par  le  cercle  (processus)  suivant: 


Figure  39  Cycle  Qualité 


Pour  initier  et  maintenir  ce  cycle  il  faut  cependant  des  conditions  minimales  permettant 
l'acquisition  probable  d'un  résultat  correct  conforme  aux  spécifications  et  qui  sont  souvent 
considérées  comme  étant: 

•  Le  niveau  de  détail  du  diagnostique  qualité  (SWOT  de  la  qualité) 

•  La  qualité  des  intervenants 

•  La  qualité  des  matières,  produits  achetés  et  sous-traitance 

•  La  qualité  des  équipements  utilisés 

•  La  qualité  de  l'information 

La  maîtrise  de  ces  conditions  ne  peut  être  obtenue  que  dans  le  cadre  d'une  organisation,  fiable 
et  cohérente  comportant  aussi  son  propre  système  de  surveillance. 


48  Moyens  mis  en  oeuvre  pour  garantir  et  prouver  le  niveau  que  le  niveau  de  qualité  est  maintenu  ou 
constamment  amélioré. 
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L'assurance  de  la  qualité  dans  les  projets  garantit  elle  que  tous  les  contrôles  et  tests  requis  sur 
la  base  des  normes  ou  du  système  de  gestion  de  la  qualité  sont  préparés  et  exécutés  de 
manière  claire  et  efficace,  et  qu'ils  sont  documentés  de  manière  suffisante.  Font  aussi  partie 
des  tâches  de  l'assurance  de  la  qualité  les  rapports  à  établir  sur  l'exécution  des  activités,  sur  les 
résultats  obtenus  et  sur  les  tendances  constatées  ainsi  que  sur  le  fameux  "COQ",  c'est-à-dire 
(conformément  à  la  norme  AFNOR  X  50-126:  Guide  d'évaluation  des  coûts  résultants  de  la 
non  qualité)  le  Coût  d'Obtentation  la  Qualité  qui  consiste  à  vérifier  que  les  coûts  engendrés 
par  une  démarche  de  gestion  de  la  qualité  a  un  retour  sur  investissement  par  rapport  aux 
Coûts  de  Non-Qualité  (CNQ)  eux-mêmes  étant  la  somme  des  coûts  de  non-qualité  interne 
(CI)  et  coûts  de  non-qualité  externe  (CE).  Signalons  aussi  l'indicateur  de  Coût 
d'investissement  dans  la  Qualité  (CIQ)  qui  est  la  somme  du  coût  d'évaluation  (ou  de 
détection)  et  du  coût  d'obtention  de  la  qualité.  Il  arrive  aussi  que  l'on  distingue  dans  cette 
catégorie: 

1 .  Les  Coûts  Contrôlables  (CC)  qui  sont  les  dépenses  volontaires  générées  pour 

maintenir  un  certain  niveau  de  qualité.  Ces  coûts  sont  eux-mêmes  séparés  souvent  en 
deux  sous-catégories: 

a.  Les  Coûts  de  Prévention  (CP)  qui  est  l'investissement  humain  et  matériel 
engagés  pour  vérifier,  prévenir  et  réduire  les  anomalies  c'est-à-dire  pour 
financer  les  actions  menées  au  niveau  des  causes  des  anomalies. 

b.  Les  Coûts  de  Détection  (CD)  ou  d'Évaluation  (CE)  qui  sont  les  coûts 
engagés  pour  vérifier  la  conformité  des  produits  aux  exigences  qualité  c'est-à- 
dire  pour  financer  la  recherche  des  anomalies 

Nous  pouvons  résumer  les  coûts  qualité  par  l'excellent  graphique  suivant  (qui  est  le  même  que 
celui  du  modèle  de  Wilson  en  logistique): 


Maximum 

100%  de  100%  de 


produits  défectueux  produits  conformes 

Niveau  de  Qualité 

Figure  40  Graphique  des  coûts  relatifs  à  la  non-qualité  (source:  ISBN  978-2-297-01111-2) 
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ou  par  le  tableau  suivant: 


Coûts  de  correction 

Coûts  de  prévention 

=  coûts  de  non-qualité 

=coûts  liés  à  la  prévention  des  problèmes 

Coûts  des  anomalies 
internes 

Coûts  des  anomalies 

externes 

Coûts  de  correction 

Coûts  de  prévention 

...avant  que  le 
produit  ne  quitte 
l'entreprise 

...après  que  le  produit 
a  quitté  l'entreprise 

=  dépenses  pour 
vérifier  la  conformité 

=  investissement 
pour  réduire  les 
anomalies  de  façon 
préventive 

Pour  information,  le  PMBOK  v3  identifie  les  coûts  suivants  dans  le  domaine  de  la  gestion  de 
la  qualité: 

-  Coût  de  la  formation  continue  et  préventive  (formation  périodiques  obligatoires) 

-  Coût  de  la  documentation  (processus,  check-lists,  formulaires  d'audits) 

-  Adaptation  et  acquisition  d'équipements,  machines  et  accessoires 
Tests  destructifs  ou  non  destructifs,  échantillonnages 

Mais  qui  doivent  (toujours  selon  la  proposition  du  PMBOK  v3)  d'économiser  au  niveau: 

-  De  la  perte  de  temps  à  recréer  la  roue  en  interne  (rework) 

-  Des  retouches  produits 

-  Des  déchets 

-  Des  garanties  ou  retours  en  magasin 

-  Des  actions  de  poursuite  judiciaire 

Pour  arriver  à  ces  objectifs  qualitatifs  et  quantitatifs,  il  est  donc  nécessaire  d'abord  d'y 
consacrer  un  certain  temps  d'étude.  Cependant,  avant  de  commencer  je  tiens  à  partager  ma 
conviction  +  une  proposition  personnelle: 

Conviction:  Toute  entreprise  de  plus  de  50  employés  qui  n'a  pas  un  responsable  qualité  ou 
qui  n'a  pas  de  responsables  qualité  par  groupe  de  l'OOO  employés  n'est  absolument  pas 
sérieuse  et  se  moque  alors  de  ses  clients  (et  de  ses  employés)  car  c'est  alors  une  preuve  de  son 
désintérêt  à  fournir  une  prestation  ou  un  produit  conforme  aux  règles,  attentes,  conditions  de 
travail  et  règles  de  maintenance  auxquelles  on  peut  être  en  droit  de  s'attendre! 

Proposition:  Dans  les  entreprises  où  la  direction  n'est  pas  motivée  à  engager  des  ressources 
responsables  de  la  qualité  nous  pouvons  proposer  que  toute  anomalie/accident  qualité  doit 
pouvoir  être  quantifiée  en  termes  de  coûts  (ce  qui  va  beaucoup  intéresser  la  direction)  et  ces 
mêmes  coûts  doivent  alors  être  payés  par  le  département  concerné  au  département  qualité  en 
tant  que  budget  de  fonctionnement  (ou  un  certain  pourcentage).  L'idée  étant  alors  que  les 
départements  ayant  beaucoup  de  problèmes  qualité  voient  leur  budget  de  fonctionnement 
diminuer  à  cause  des  pénalités,  ce  qui  finance  un  département  qualité  qui  les  aidera  à  mettre 
en  place  les  moyens  pour  éviter  ces  problèmes,  et  le  jour  où  tout  va  bien  (le  jour  où  le 
département  qualité  n'est  plus  financé  par  les  autres. . .)  le  département  qualité  disparaît  de  lui- 
même. 
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U 


Excellence 


© 


Management  qualité 

(amélioration  continue, 
suivi  et  anticipation) 


Assurance  qualité 

(preuve  de  la 
confirmité) 


Maîtrise 

(recherche  de 
conformité) 


Soit  sous  forme  un  peu  plus  détaillée: 


Maîtrise 

Assurance 

Management 

Prévoir 

Démontrer 

ce  que  l'on  va  faire 

que  l'on  respect 

PILOTAGE 

/ 

Ecrire 

ce  qui  a  été  prévu 

Faire  vérifier  par  un  audit 

Faire 

ce  qui  a  été  écrit 

que  le  système  est  adéquat 

AMÉLIORATION 

Conserver 

Corriger 

CONTINUE 

la  trace 

les  erreurs 

Enfin,  rappelons  quelques  éléments: 

1 .  Pour  des  raisons  de  coûts  de  la  qualité  la  société  Petrobras  aurait  fièrement  annoncé 
dans  les  médias  qu'elle  a  réussi  à  couper  les  coûts  inutiles  de  la  qualité  dans  la 
fabrication  des  plates-formes  pétrolières  en  inaugurant  le  principe  sur  la 
plate-forme  P36... 

Résultat:  Elle  coule  suite  au  non-respect  des  normes  qualité  de  sécurité  et 
500'000'000$  sont  maintenant  sous  l'eau  plus  quelques  humains  avec. . . 
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2.  Pour  des  raisons  de  coût,  la  société  Tepco  aurait  évité  de  mettre  en  place  trop  de 

système  de  redondance  dans  leur  centrale  nucléaire  et  aurait  évité  de  faire  les  contrôles 
de  maintenance  correctement  pendant  10  ans.... 

Résultat:  Accident  nucléaire  de  Fukushima  en  201 1  et  coûts  directs  estimés  à  environ 
l'000'000'000$  plus  quelques  humains  sacrifiés... 


Nous  voyons  alors  bien  à  travers  ces  deux  exemples  (et  je  pourrai  en  donner  une  centaine 
d'autres  sur  le  niveau  de  qualité  interne  que  j'ai  pu  observer  dans  de  nombreuses 
multinationales),  que  nous  connaissons  les  entreprises  qui  affichent  de  bons  bénéfices  nets... 
mais  ce  que  nous  ignorons,  ce  sont  les  entreprises  qui  ont  de  bonnes  méthodes  qualité. 

Ainsi,  contrairement  à  ce  que  disent  beaucoup  de  consultants  qualité,  la  qualité  n'a  pas  pour 
rôle  que  de  satisfaire  les  exigences  implicites  ou  explicites  des  clients  car  celles-ci  peuvent 
être  absurdes,  irrespectueuses  de  l'étique,  des  lois  ou  de  la  simple  logique!  La  qualité  serait 
plutôt  l 'Ensemble  des  règles  de  bonnes  pratiques  de  conception  d’un  produit,  respectueuses  de 
demandes  du  mandant,  de  la  philosophie  de  travail  du  mandataire,  des  règles  sociales, 
légales  et  des  normes  internationales  approuvées  que  tout  audit  interne  ou  externe  à  tout 
moment  doit  pouvoir  démontrer  le  respect. 

Bref,  outre  le  respect  évident  des  normes  de  qualité/sécurité/environnementales  qui  devrait 
être  obligatoire  et  contrôlé  régulièrement  par  des  évangélistes  passionnés  et  neutres 
(indépendants)  dans  ce  domaine  d'activité,  dans  les  cours  de  gestion  de  projet  PMI,  ITIL  ou 
CMMi  souvent  il  est  demandé  comment  savoir  si  un  indicateur  statistique  de  contrôle  de 
qualité  (produit  ou  processus)  est  un  bon  indicateur. 
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Il  faut  d'abord  savoir  avant  de  répondre  à  cette  question  que  la  qualité  est  devenue  aujourd'hui 
un  nouveau  défi  pour  de  nombreuses  entreprises  face  à  une  économie  en  baisse  de  régime  et 
face  au  Japon  qui  envahit  le  monde  occidental  par  des  produits  bon  marché  et  de  bonne 
qualité. 

L'amélioration  de  la  qualité  des  produits  fait  partie  depuis  longtemps  des  préoccupations 
essentielles  des  entreprises.  Actuellement,  cette  notion  s'étend  à  l'ensemble  des  organisations 
quelles  qu'elles  soient:  industries,  sociétés  de  service  ... 

La  statistique  a  une  place  essentielle  dans  ce  mouvement  qualité  par  les  techniques  et  la 
méthodologie  qu'elle  propose  pour  aider  à  une  résolution  objective,  méthodique  et  rigoureuse 
des  problèmes. 

Dans  cette  introduction,  nous  tentons  de  replacer  la  Maîtrise  Statistique  de  la  Qualité  (MSQ) 
dans  son  contexte  historique  et  d'en  présenter  la  définition  et  la  philosophie. 

Il  existe  pour  cela  des  techniques  assez  élaborées  de  niveau  licence  voir  doctorat  universitaire 
qui  dépassent  largement  un  cours  de  gestion  de  projets  pour  des  non  spécialistes 
(mathématiciens,  physiciens,  économistes). 

Nous  pouvons  cependant  donner  un  aperçu  d'une  technique  pratique  et  à  la  mode  qui  se 
nomme  Six  Sigma  (ISO  13053-1:2011).  Nous  allons  reprendre  ici  à  nouveau  un  exemple 
donné  par  mon  site  Sciences. ch49  (donc  de  nombreuses  démonstrations  s'y  trouvent  que  nous 
omettrons  ici  sinon  le  document  ferait  plusieurs  millier  de  pages)  qui  peut  très  bien  s'appliquer 
à  la  gestion  de  projets. 

Six  sigma  est  à  l'origine  une  démarche  qualité  limitée  dans  un  premier  temps  aux  techniques 
de  Maîtrise  Statistique  des  Procédés  (SPC:  Statistical  Process  Control).  La  Maîtrise 
Statistique  de  la  Qualité  (MSQ)  ou  Statistical  Quality  Control  (SQC)  a  elle  vu  le  jour  aux 
États-Unis  dans  les  années  30.  W.A.  Shewhart,  qui  travaillait  comme  physicien  à  Bell 
Téléphoné  Laboratories  aux  États-Unis,  est  considéré  comme  le  "père"  du  SQC.  Entre  1924  et 
1930,  il  a  développé  la  plupart  des  techniques  de  base  du  SQC  qui  sont  utilisées  actuellement. 
C'est  spécialement  pour  les  cartes  de  contrôle  qu'il  est  connu.  Il  utilisa  celles-ci  pour  de 
nombreux  procédés  de  sa  société  et  démontra  qu'elles  étaient  réellement  efficaces  pour  réduire 
leur  variabilité.  A  la  même  époque,  H.  Dodge  et  H.  Roming,  également  de  Bell  Lab, 
développèrent  les  fondements  du  contrôle  de  réception  (plans  d'échantillonnage),  autre  outil 
fondamental  du  SQC. 

Remarque:  La  lettre  grecque  "Sigma"  symbolisant  comme  nous  le  savons  bien  l'écart-type 
statistique  (voir  mon  livre  de  Mathématiques  Appliquées). 

Pendant  la  seconde  guerre  mondiale,  l'armée  américaine  commença  à  pratiquer  les  méthodes 
de  Shewhart.  Elle  encourageait  ses  fournisseurs  à  également  les  utiliser  et  offrait  des  cours 
pour  leur  expliquer  comment  les  appliquer.  Suite  à  cela,  dans  les  années  40  et  50,  de 
nombreuses  usines  américaines  utilisaient  le  SQC  et  la  Société  Américaine  pour  le  Contrôle 
de  Qualité  (American  Society  for  Quality  Control  -  ASQC)  a  été  fondée  en  1958. 


49  Le  lecteur  intéressé  y  trouvera  les  démonstrations  mathématiques  détaillées  de  techniques  avancées  de  qualité 
comme  l’AMDEC,  le  contrôle  de  réception,  les  détails  sur  Six  Sigma,  les  cartes  de  contrôle,  etc. 
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Le  Dr.W.  Edwards  Deming  (statisticien  et  physicien  théoricien  considéré  comme  le  père  de  la 
qualité  quantitative)  se  fit  également  connaître  avant  la  seconde  guerre  mondiale  pour  ses 
idées  dans  le  domaine  de  la  qualité.  Il  défendait  le  fait  que  le  management  devait  prendre  plus 
de  responsabilités  dans  l'amélioration  des  performances  d'une  organisation  et  que  le  style  de 
management  en  vigueur  aux  États-Unis  devait  changer.  Il  prônait  aussi  l'utilisation  des 
méthodes  statistiques  proposées  par  Shewhart  mais  les  américains  ne  se  sont  pas  vraiment 
intéressés  à  son  discours  trop  précurseur  comme  à  l'habitude  pour  un  scientifique  par  rapport 
au  reste  du  monde. 

Les  méthodes  de  SQC  furent  diffusées  en  Angleterre  dès  1931.  Les  autres  pays  européens 
commencèrent  à  les  utiliser  dans  les  années  50  suite,  dans  la  plupart  des  cas,  à  des  cours 
donnés  par  des  instructeurs  américains.  L'organisation  européenne  de  contrôle  de  qualité  a  été 
créé  en  1965  (European  Organisation  for  Quality  Control). 

Aux  États-Unis,  le  nombre  de  compagnies  utilisant  le  SQC  commença  à  décroître  dans  les 
années  50  principalement  parce  que  l'armée  ne  s'y  intéressait  plus.  Dans  les  années  60-70,  la 
plupart  des  compagnies  avaient  stoppé  l'utilisation  des  techniques  SQC  et  les  universités 
américaines  arrêté  leur  enseignement  dans  le  domaine. 

La  situation  était  bien  différente  au  Japon:  après  la  seconde  guerre  mondiale,  le  Japon  était 
dévasté,  il  n'avait  aucune  base  industrielle  solide  et  pratiquement  aucune  ressource  naturelle. 

Il  reconnut  que  le  seul  moyen  de  survivre  était  de  fabriquer  et  vendre  des  biens  de  très  bonne 
qualité.  Les  années  50  ont  vu  les  japonais  utiliser  les  méthodes  de  SQC  de  façon  croissante. 
Cet  intérêt  est  en  particulier  expliqué  par  plusieurs  visites  et  conférences  faites  par  le 
Dr.  W.  E.  Deming  au  Japon.  En  1949,  il  fut  invité  à  donner  des  cours  sur  les  méthodes 
statistiques  dans  l'industrie  par  le  JUSE  (Japanese  Union  of  Scientists  and  Engineers). 

Dr.  Juran  a  également  donné  des  cours  en  1954  à  des  managers  ;  il  confirma  l'idée  que  le 
contrôle  statistique  de  qualité  était  un  outil  de  base  pour  le  management.  Fin  des  années  60, 
les  japonais  utilisaient  intensément  les  méthodes  proposées  par  le  Dr.  Deming  et  faisaient  des 
progrès  très  rapides  dans  les  domaines  de  la  qualité  et  de  l'augmentation  de  la  productivité 

Les  Japonais  ont  rapidement  réalisé  que,  contrairement  aux  disciplines  scientifiques  telles  que 
la  chimie  ou  la  physique,  la  maîtrise  de  la  qualité  n'implique  pas  seulement  l'utilisation  de 
techniques  mais  également  de  nombreux  facteurs  humains  et  culturels.  Ils  créèrent  le  QC 
Circle  élément  clef  de  leur  réussite.  Deux  noms  prédominent  au  Japon  dans  le  domaine  du 
contrôle  statistique  de  la  qualité:  K.  Ishikawa  et  ses  fameux  7-tools  et  Taguchi  qui  introduisit 
le  parameter  design  dans  les  années  70. 

Au  vu  de  l'importance  croissante  prise  par  le  Japon  dans  le  marché  économique  mondial,  les 
pays  industrialisés  ont  voulu  savoir  pourquoi.  En  1980,  un  journaliste  américain  écrivait:  “Si 
le  Japon  peut,  pourquoi  pas  nous?  "  Ceci  a  mené  à  un  regain  d'intérêt  pour  le  contrôle 
statistique  de  la  qualité  et  pour  la  philosophie  de  Deming  aux  Etats-Unis  De  nombreuses 
compagnies  américaines,  spécialement  l'industrie  automobile  (ex.  Ford,  General  Motor), 
utilisent  actuellement  les  méthodes  SQC  et  insistent  pour  que  leurs  fournisseurs  fassent  de 
même.  D'autres  réalisent  que  les  méthodes  proposées  par  le  Dr  Deming  ne  sont  pas  seulement 
utiles  dans  les  industries  pour  améliorer  la  qualité  et  la  productivité  mais  le  sont  aussi  dans 
d'autres  activités  telles  que  les  sociétés  de  services  (banques,  transports,  hôpitaux  ...)  50  ans 
après... 

Six  Sigma  (devenu  la  référence  qualité  mondiale  en  gestion  de  projet  en  ce  début  de  21eme 
siècle)  est  fondée  sur  une  règle  théorique  et  idéale  (provenant  du  statisticien  très  connu  en 
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gestion  de  projets:  Deming):  pour  satisfaire  les  clients,  il  faut  délivrer  des  produits  de  qualité 
(quels  qu'ils  soient!). 

Les  processus  de  fabrication  dans  l'industrie  de  pointe  ayant  une  forte  tendance  à  devenir 
terriblement  complexes,  il  faut  noter  que  les  composants  de  base  utilisés  pour  chaque  produit 
ne  sont  pas  toujours  de  qualité  ou  de  performance  égale.  Et  si  de  surcroît,  les  procédures  de 
fabrication  sont  difficiles  à  établir,  la  dérive  sera  inévitablement  au  rendez-vous. 

Que  ce  soit  pour  l'une  ou  l'autre  raison,  au  final  bon  nombre  de  produits  seront  en  dehors  de  la 
normale  et  s'écarteront  ainsi  de  la  fourchette  correspondant  à  la  qualité  acceptable  pour  le 
client.  Cette  dérive  est  fort  coûteuse  pour  l'entreprise,  la  gestion  des  rebuts,  des  retouches  ou 
des  retours  clients  pour  non-conformité50  générant  des  coûts  conséquents  amputant 
sérieusement  les  bénéfices  espérés. 

La  méthode  Six  Sigma  offre  des  techniques  et  outils  simples  accessibles  à  des  non 
mathématiciens  ou  ingénieurs  pour  contrôler  la  capacité  de  production  des  processus  tout  en 
tentant  de  réduire  les  défauts.  Par  exemple,  les  inégalités  de  Markov  ou  Bienaymé- 
Tchebychev  (voir  mon  livre  de  Mathématiques  Appliquées)  sont  passées  sous  silence  dans 
cette  méthode  ce  qui  est  assez  étonnant... 

Cette  méthode  se  base  principalement  sur  les  lois  de  distributions  classiques  (voir  mon  livre 
de  Mathématiques  Appliquées)  avec  un  vocabulaire  propre  à  ce  standard  américain,  la 
recherche  opérationnelle  (voir  mon  livre  de  Mathématiques  Appliquées),  la  théorie  de  la 
décision  et  jeux  (voir  mon  livre  de  Mathématiques  Appliquées). 


Écrire  ce  que  l'on  fait,  faire  ce  que  l'on  écrit,  et  le  prouver... 


8. 6.4.6. 1  Les  14  points  de  Deming 

La  philosophie  de  W.  Edwards  Deming  est  considérée  par  beaucoup  comme  une  base  pour 
l'implantation  des  outils  de  la  qualité  dans  une  entreprise.  Deming  a  résumé  sa  philosophie  en 
14  points  (Deming  W.E.  [1980]).  L'adhérence  du  management  japonais  à  ces  principes  est 
considérée  comme  un  facteur  très  important  du  succès  industriel  du  Japon. 

Afin  de  donner  un  aperçu  de  la  philosophie  de  Deming,  nous  donnons  ici  les  14  points  de 
Deming  accompagnés  de  quelques  commentaires. 


50  Une  non-conformité  est  le  non-respect  d'une  exigence  définie  dans  la  spécification  du  produit,  du  service,  du 
processus  de  réalisation,  ou  encore  par  rapport  aux  procédures  décrivant  le  système  qualité  de  l'entreprise. 
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Pour  Deming,  les  méthodes  statistiques  de  la  qualité  peuvent  apporter  une  aide  significative 
aux  entreprises  qui  parviennent  à  les  appliquer  avec  succès.  La  participation  et  le  soutien  du 
management  dans  l'effort  d'amélioration  de  la  qualité  est  une  composante  primordiale  pour  le 
succès  de  l'implantation  du  SQC.  Les  outils  de  base  du  SQC  doivent  devenir  connus  et  utilisés 
par  tous  dans  une  organisation.  Une  formation  continue  aux  outils  et  aux  principes  de 
l'amélioration  de  la  qualité  est  aussi  nécessaire  pour  atteindre  leur  maîtrise.  L'amélioration  de 
la  qualité  doit  devenir  une  partie  de  la  culture  de  l'organisation. 

1.  Créez  un  esprit  visant  à  l'amélioration  continue  des  produits  et  services  dans  le  but 
de  devenir  compétitif,  de  rester  dans  le  marché  et  de  fournir  des  emplois.  Le 
management  doit  être  convaincu  que  l'entreprise  vivra  encore  longtemps  et  viser 
des  résultats  à  long  terme  plutôt  que  des  profits  à  court  terme.  Il  doit  pour  cela 
prévoir  des  ressources  pour  la  recherche,  le  développement  et  la  formation.  Les 
choix  stratégiques  se  feront  sur  base  des  besoins  de  la  personne  la  plus  importante 
de  la  chaîne:  le  CLIENT. 

2.  Adoptez  une  nouvelle  philosophie.  Nous  sommes  dans  un  nouvel  âge  économique. 
Le  management  doit  s'éveiller  au  challenge,  doit  prendre  ses  responsabilités  et 
prendre  la  direction  du  changement.  Il  doit  accepter  que  l'ancienne  pratique  qui 
consistait  à  accepter  une  certaine  proportion  de  produit  défectueux  soit  dépassée. 
L'amélioration  de  la  qualité  d'un  produit  est  un  effort  continu  qui  ne  doit  jamais 
s'arrêter. 

3.  Cessez  d'utiliser  l'inspection  pour  obtenir  la  qualité.  Éliminez  le  besoin 
d'inspection  exhaustive  en  construisant  la  qualité  dans  le  produit  dès  sa  conception. 
Inspecter  du  produit  fini  permet  de  retirer  la  proportion  de  produit  défectueux  mais 
vient  trop  tard.  Un  tel  produit  a  déjà  trop  coûté  et  une  telle  pratique  n'améliore  en 
rien  le  procédé.  Le  contrôle  doit  se  faire  en  cours  de  production  par  l'application  de 
méthodes  de  SPC  ou  mieux,  avant  production  dans  le  design  du  produit  et  du 
procédé  de  fabrication. 

4.  Ne  basez  plus  le  choix  d'un  fournisseur  uniquement  sur  base  de  ses  prix  mais 
également  sur  la  qualité  de  ses  produits.  Tentez  d'utiliser  un  seul  fournisseur  pour 
chaque  produit  et  basez  votre  relation  sur  la  loyauté  et  la  confiance.  Le  prix  d'un 
fournisseur  ne  peut  être  considéré  que  si  on  le  met  en  relation  avec  la  qualité  du 
produit  et  le  coût  total  d'utilisation  d'un  produit  qui  peut  avoir  des  défauts.  On 
recherchera  des  fournisseurs  qui  pratiquent  eux-mêmes  des  méthodes  de  SQC  dans 
leur  entreprise. 

5.  Améliorez,  constamment  et  pour  toujours,  le  système  de  production  et  de  service  à 
la  clientèle  dans  le  but  d'améliorer  la  qualité  et  la  productivité  et,  en  conséquence, 
de  décroître  les  coûts.  Les  outils  statistiques  peuvent  aider  à  déterminer  qui  a  la 
responsabilité  des  actions  à  mener  pour  l'amélioration  de  la  qualité:  action  locale 
ou  globale  sur  le  système. 

6.  Instaurez  la  notion  de  formation.  Formez  les  employés  de  tous  niveaux  au  travail 
dont  ils  sont  responsables.  Le  management  doit  fournir  aux  employés  les  moyens 
et  outils  pour  faire  correctement  leur  travail,  la  formation  en  fait  partie.  Des 
méthodes  statistiques  peuvent  être  utilisées  pour  tester  si  un  travailleur  est  bien 
formé.  Un  travailleur  n'est  pas  formé  tant  que  son  travail  n'est  pas  en  contrôle 
statistique. 
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7.  Instaurez  un  leadership  constructif.  Le  rôle  du  leadership  est  d'aider  et  d'entraîner 
les  personnes  à  faire  un  meilleur  travail.  Supervision  ne  veut  pas  dire  surveillance. 
La  supervision  du  management  est  nécessaire  plus  que  tout  ainsi  que  la  supervision 
des  travailleurs  de  la  production. 

8.  Supprimez  la  crainte  de  manière  à  assurer  que  chaque  employé  travaille  utilement 
pour  la  compagnie.  La  peur  (du  responsable,  de  l'erreur, ...)  existe  dans  de 
nombreuses  entreprises.  Elle  inhibe  les  facultés  de  l'employé  et  l'empêche  de  se 
donner  à  fond.  Un  environnement  doit  être  créé  pour  aider  les  travailleurs  à  se 
sentir  à  l'aise  pour  poser  des  questions,  faire  des  suggestions,  avertir  des  problèmes 
rencontrés. 

9.  Supprimez  les  barrières  entre  départements.  Les  personnes  de  la  recherche,  de  la 
conception,  de  la  vente  et  de  la  production  doivent  travailler  en  équipe  pour 
prévoir  les  problèmes  de  fabrication  et  d'utilisation  qui  peuvent  être  rencontrés 
avec  le  produit  ou  le  service  (il  n'y  a  pas  de  domaines  sacré!).  Ici  encore,  les 
méthodes  statistiques  peuvent  aider  les  équipes  multidisciplinaires  à  travailler 
ensemble. 

10.  Éliminez  les  slogans,  recommandations  ou  objectifs  destinés  aux  travailleurs  qui 
prônent  d'annuler  la  proportion  de  produit  défectueux  ou  qui  demandent  de 
nouveaux  niveaux  de  productivité.  Des  objectifs  chiffrés  ont  en  général  un  effet 
négatif  et  frustrant.  Un  objectif  tel  que  "0  défectueux"  n'a  aucune  chance  d'aboutir 
s'il  n'est  pas  accompagné  d'un  plan  d'analyse  du  procédé  de  fabrication  et  des 
moyens  de  l'améliorer. 

11.  Éliminez  le  travail  traditionnel  du  secteur  de  fabrication.  Remplacez  le 
management  quantifiable  rigoureusement  et  scientifiquement.  Des  quotas  donnés 
par  le  management  sans  relation  avec  la  notion  de  qualité  montrent  que  le 
management  ne  comprend  pas  ou  ne  s'intéresse  pas  au  procédés  lui-même  et  aux 
façons  de  l'améliorer  indéfiniment. 

12.  Supprimez  les  barrières  qui  enlèvent  au  travailleur  la  fierté  de  son  métier.  Le 
management  doit  écouter  les  travailleurs  en  charge  d'un  travail.  Ce  sont  eux  qui 
sont  les  mieux  placés  pour  faire  des  suggestions  ou  commentaires.  Le  travailleur 
est  un  facteur  primordial  dans  la  bonne  marche  d'une  société  et  n'est  pas  seulement 
une  "machine"  du  système. 

13.  Instituez  un  programme  énergique  d'enseignement,  de  recyclage  et 
d'autoapprentissage.  Les  employés  doivent  être  convaincus  que  le  management 
investit  dans  leur  futur  en  leur  donnant  l'opportunité  de  se  former  pour  être 
préparés  aux  changements  futurs.  L'enseignement  des  méthodes  statistiques 
simples  est  nécessaire  pour  tous  les  employés.  Les  formations  doivent  être 
adaptées  aux  besoins,  aux  changements  prévus,  aux  méthodes  utilisées  et  aux 
besoins  des  clients. 

14.  Pour  accomplir  la  transformation,  faite  participer  chaque  personne  de 
l'organisation.  La  transformation  concerne  chacun.  Une  nouvelle  structure  doit  être 
mise  en  place  pour  que  l'application  des  13  premiers  points  soit  possible. 


Ingénierie  de  Gestion  de  projets 


396/547 


La  Qualité  offre  une 
reconnaissance 
internationale 


La  Qualité  offre  une 
démarche  structurée  et 
méthodique 


La  Qualité  offre  un 
gage  de  confiance 


8.6.4.6.2  Exigences  générales 

Les  exigences  générales  pour  atteindre  un  objectif  de  qualité  sont  parfaitement  bien  exprimées 
et  résumés  dans  le  standard  ISO  9001.  Selon  la  version  2008  de  cette  norme,  la  qualité  est: 
L'aptitude  d'un  ensemble  de  caractéristiques  intrinsèques  d'un  produit,  d'un  système,  d'un 
processus  à  satisfaire  les  exigences  des  clients  et  autres  parties  intéressées. 

Il  faut  ainsi  au  minimum  et  en  permanence: 

-  Déterminer  les  processus  nécessaires  à  la  gestion  et  au  contrôle  de  la  qualité  (et  de  la 
non-qualité!)  ainsi  qu'à  leur  application 

-  Déterminer  les  séquences  et  interactions  de  ces  processus 

-  Déterminer  les  critères  et  les  méthodes  nécessaires  pour  assurer  l'efficacité  du 
fonctionnement  et  la  maîtrise  des  processus 

-  Assurer  la  disponibilité  des  ressources  et  des  informations  nécessaires  au 
fonctionnement  et  à  la  surveillance  de  ces  processus  (autocontrôlé) 

-  Surveiller,  mesurer,  analyser  et  optimiser  les  processus  (conformément  à  un  processus 
général  à  ce  sujet) 

-  Le  développement  de  tout  projet  doit  être  documenté  (étape  par  étape)  avec  procès- 
verbaux  des  réunions.  Au  minimum  pour  ISO  9001  les  exigences  fonctionnelles,  de 
performance 

-  Mettre  en  oeuvre  et  donner  le  pouvoir  nécessaire  pour  obtenir  les  résultats  de  qualité 

La  direction  doit  obliger  les  employés  quel  que  soit  leur  niveau  hiérarchie  à  suivre  les 
directives  de  l'équipe  qualité  validées  par  la  direction 

-  Le  responsable  qualité  doit  dénoncer  toute  non-conformité  cachée  ou  données 
modifiées  intentionnellement  aux  autorités  compétentes 

-  Des  revues  (réunions)  et  audit  de  qualité  doivent  être  mis  sur  place  au  moins  1  fois  par 
trimestre  avec  procès-verbaux  obligatoires 
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Les  contrôles  inopinés  doivent  être  mis  en  place  et  exécutés  par  un  membre  chevronné 
du  département  qualité. 

-  Les  responsabilités  et  degrés  décisionnels  doivent  être  documentés 

-  Un  responsable  qualité  doit  être  engagé  par  tranche  de  100  employés. 

Le  responsable  de  projet  doit  être  en  possession  d'une  charte  (politique  et  objectifs)  de  qualité 
et  l'ensemble  des  processus  et  anomalies  qualité  doivent  être  documentés.  Le  domaine 
d'application  du  système  de  gestion  de  la  qualité,  y  compris  le  détail  et  la  justification  des 
exclusions,  doivent  se  trouver  explicitement  dans  la  charte. 


E=mc2 


Meeting  Corporate 


Par  ailleurs,  une  procédure  doit  être  établie  afin  de  définir  les  contrôles  nécessaires  pour 


approuver  les  documents  quant  à  leur  adéquation  avant  diffusion  (en  utilisant  le  concept  de 
version  majeure  et  mineure  par  exemple)  et  avoir  un  suivi  de  leur  évolution  (mise  à  jour).  Il 
faut  également  s'assurer  dans  cette  procédure  que  les  documents  produits  au  sein  de 
l'organisation  restent  lisibles  et  facilement  identifiables  les  temps  légal  nécessaire. 


Le  responsable  de  projet  doit  aussi  établir  (si  l'entreprise  ne  l'a  pas  déjà  fait)  une  procédure 


documentée  pour  définir  les  contrôles  nécessaires  associés  à  l'identification,  au  stockage,  à  la 
protection,  à  l'accessibilité,  à  la  conservation  et  à  l'élimination  des  enregistrements. 

Par  ailleurs,  les  résultats  des  audits,  des  retours  d'informations  clients  doivent  être  compilés  et 
documentés  pour  apporter  la  preuve  que  les  processus  satisfont  aux  exigences. 

Dans  cette  optique  il  ne  faut  jamais  oublier  que  les  exigences  qualité  continue  même  une  fois 
le  livrable  livré. . .  d'où  la  nécessité  d'assigner  un  identifiant  unique  de  traçabilité  à  un  projet 
comme  l'exige  ISO  9001. 
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Figure  41  Résumé  élémentaire  des  composants  de  base  de  la  qualité 


Voyons  maintenant  quelques  outils  importants  du  contrôle  quantitatif  de  la  qualité.  Pour 
l'instant,  je  n'ai  pas  souhaité  inclure  dans  le  présent  support  tout  le  contenu  de  mon  livre  sur  le 
sujet  (environ  200  pages). 

8.6A6.3  Défauts/Erreurs 

Intéressons-nous  donc  à  exposer  pour  la  culture  générale  un  exemple  pratique  et  particulier  de 
ce  qui  n'est  qu'une  application  simple  de  la  théorie  des  statistiques  et  probabilités. 

Imaginons  une  entreprise  fabricant  trois  copies  d'un  même  produit  sortant  d'une  même  chaîne, 
chaque  copie  étant  composée  de  huit  éléments. 

Remarque:  Nous  pouvons  tout  aussi  bien  imaginer  une  société  de  services  développant 
(fabricant)  trois  copies  d'un  logiciel  (produit)  sortant  d'une  même  équipe  de  développement 
(chaîne),  chacun  composé  d'un  nombre  égal  de  modules  (éléments).  Ou  encore  imaginer  une 
société  qui  effectue  plusieurs  faut  un  même  type  de  tâche  dont  la  durée  est  censée  être  fixe 
pour  laquelle  il  y  parfois  des  variations. 

Supposons  que  le  produit  PI  a  un  défaut,  le  produit  P2  zéro  défauts  et  le  produit  P3  deux 
défauts. 
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Six  Sigma  suppose  implicitement  que  les  défauts  sont  des  variables  indépendantes  ce  qui  est 
très  rare. . .  dans  les  chaînes  de  fabrication  machines  mais  plus  courant  dans  les  chaînes  dans 
lesquelles  des  humains  sont  les  intervenants. 

Remarque:  Dans  le  cadre  de  l'exemple  du  logiciel  cela  est  peu  probable  si  nous  ne  prenons 
pas  un  exemple  dans  lequel  les  modules  sont  personnalisés  selon  les  besoins  du  client. 

La  moyenne  arithmétique  des  défauts  nommée  dans  le  standard  Six  Sigma  "Defects  Per  Unit" 
est  alors  défini  par: 


p U  _  nombre  total  de  défauts  observés 

nombre  total  d'unités  de  production  observées 


et  donne  dans  notre  exemple: 


DPU  =  -  =  1 
3 

ce  qui  signifie  en  moyenne  que  chaque  produit  a  un  défaut  de  conception  ou  fabrication. 
Attention!  Cette  valeur  n'est  pas  une  probabilité  pour  les  simples  raisons  qu'elle  peut  d'abord 
être  supérieure  à  1  et  qu'ensuite  elle  a  comme  dimension  des  [défauts]/[produits]. 

De  même,  l'analyse  peut  être  faite  au  niveau  du  nombre  total  d'éléments  défectueux  possibles 
qui  composent  le  produit  tel  que  nous  sommes  amenés  naturellement  à  définir  selon  le 
standard  Six  Sigma  le  "Defects  per  Unit  Opportunity": 


DPO  = 


DPU 


nombre  total  d'éléments  par  produits 


ainsi,  dans  notre  exemple,  nous  avons: 


nro.aw'.aw'.i.o.izs 


m 


8  8 


et  ceci  peut  être  vu  comme  la  probabilité  d'avoir  un  défaut  par  élément  de  produit  puisque 
c'est  une  valeur  sans  dimensions: 


DPO 


DPU 

défauts 

unité 

m  , 

total 

défauts 

unité 

Équation  12  DPO 

Par  extension  nous  pouvons  argumenter  que  87.5%  d'un  élément  d'une  unité  n'a  pas  de  défauts 
et  comme  Six  Sigma  aime  bien  travailler  avec  des  exemples  de  l'ordre  du  million  (c'est  plus 
impressionnant)  nous  avons  alors  les  "Defects  Per  Million  Opportunités"  qui  devient: 
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DPMO  =  DPO  •  l'OOO'OOO  =  ■  106 

m 


Équation  13  DPMO 


ce  qui  dans  notre  exemple  donne: 


DPMO  =  125  '000 


Comme  la  probabilité  D  qu'un  élément  d’une  pièce  soit  non  défectueux  est  de  87.5%  alors,  par 
l'axiome  des  probabilités  conjointes  (voir  mon  livre  de  Mathématiques  Appliquées),  la 
probabilité  qu'un  produit  dans  son  ensemble  soit  non  défectueux  est  de: 


A  8 


n  Dt  =p~[(l- DPO )  =(1  -  DPOf 

Vz'= 1..8  J  i= 1 


ce  qui  dans  notre  exemple  donne: 


n  a 

V/=1..8  J 


=  0.8758  =  0.3436  =  34.36% 


Remarque:  Dans  Six  Sigma,  les  probabilités  conjointes  sont  aussi  naturellement  utilisées  pour 
calculer  la  probabilité  conjointe  de  produits  non  défectueux  dans  une  chaîne  de  processus  P 
connectés  en  série.  Cette  probabilité  conjointe  (ou  cumulée)  est  appelée  dans  Six  Sigma 
"Rolled  troughput  yield"  et  vaut: 


f 


RTY  =  P 


V  i 


Ctf  =IPi 


Processus 


Rendement 


90%  90%  90%  90% 


RTY 

65.6% 


Rappelons  maintenant  que  la  densité  de  probabilité  d’avoir  k  fois  l'événement  p  et  N-k  fois 
l'événement  q  dans  n'importe  quel  arrangement  (ou  ordre)  est  donné  par  (voir  mon  livre  de 
Mathématiques  Appliquées): 


P(n,k)  =  Cnk  P  = - — - pkq 

k  k\(n-k)\ 


Équation  14  Loi  binomiale 


et  est  appelée  la  loi  binomiale  ayant  pour  espérance  et  écart-type  (voir  mon  livre  de 
Mathématiques  Appliquées): 


jU  =  n-  p 


r  =±>/ 


n  -  p-  q 
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Ainsi,  dans  le  standard  Six  Sigma,  nous  pouvons  appliquer  la  loi  binomiale  pour  connaître 
quelle  est  la  probabilité  d'avoir  zéros  éléments  défectueux  et  8  autres  en  bon  état  de  marche 
sur  un  produit  de  la  chaîne  de  fabrication  de  notre  exemple  (si  tous  les  éléments  ont  la  même 
probabilité  de  tomber  en  panne...): 

P(8, 0)  = - — - 0. 125°  •  0.8758  =  0. 125°  •  0.8758  =  0.3436  =  34.36% 

0!(8  —  0)  ! 

et  nous  retombons  bien  évidemment  sur  la  valeur  obtenue  avec  les  probabilités  conjointes: 

^  =  80.125  =  1  =  DPU 

cr  =  ±V8- 0.125 -0.875  =  ±0.935 

ce  qui  est  très  mauvais. . .  pour  nos  produits. 

Ou  la  probabilité  d'avoir  un  élément  défectueux  et  sept  autres  en  bon  état  sur  un  produit  de  la 
chaîne  de  fabrication: 

P{  8,1)  =  — -0.1251  -0.8757  =  —  0.1251  -0.8757  =  0.3436  =  39.26% 

1  !(8  —  1)  !  1  !7  ! 

nous  voyons  que  la  loi  binomiale  nous  donne  39.26%  de  probabilité  d'avoir  un  élément 
défectueux  sur  8  dans  un  produit. 

Par  ailleurs,  dans  le  chapitre  de  Statistiques,  nous  avons  démontré  que  lorsque  la  probabilité  p 
est  très  faible  et  tend  vers  zéro  mais  que  toutefois  la  valeur  moyenne  n  ■  p  tend  vers  une 
valeur  fixe  si  n  tend  vers  l'infini,  la  loi  binomiale  de  moyenne  ju  =  n-  p  avec  k  épreuves  était 
donnée  alors  donnée  par: 


A 


Pk=P(X=k)  =  p(k)  =  Z-e 

kl 


Equation  15  Loi  de  Poisson 


avec: 


jU  =  n-  p 

(T  =  ±JÛ 

Équation  16  Variance,  Espérance  de  la  loi  de  Poisson 


Ce  que  Six  Sigma  note  naturellement: 


p(k)  = 


DPUk  _DPU 

- e 

kl 


avec: 


p  =  DPU 

ct  =  ±^[dpU 
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Ainsi,  dans  notre  exemple,  il  est  intéressant  de  regarder  la  valeur  obtenue  (qui  sera  forcément 
différente  étant  donné  que  nous  sommes  loin  d'avoir  une  infinité  d'échantillons  et  que  p  est 
loin  d'être  petit)  en  appliquant  une  telle  loi  continue  (la  loi  continue  la  plus  proche  de  la  loi 
binomiale  en  fait): 


p{k)  =  tLe-V  =tLe-n-P 
k\  k\ 


A^-o.  125-8  =  —e~1  =  0.3679  =  36.79% 
0!  0! 


avec: 


//  =  1  cr  =  ±1 

ce  qui  est  un  résultat  encore  plus  mauvais  qu'avec  la  loi  binomiale. 

Cependant,  si  p  est  fixé  au  départ,  la  moyenne  p  =  n  -  p  tend  également  vers  l'infini 
théoriquement  dans  la  loi  de  Poisson  de  plus  l'écart-type  n-  p-q  tend  également  vers  l'infini. 

Si  nous  voulons  calculer  la  limite  de  la  distribution  binomiale,  il  s'agira  donc  de  faire  un 
changement  d'origine  qui  stabilise  la  moyenne,  en  0  par  exemple,  et  un  changement  d'unité 
qui  stabilise  l'écart,  à  1  par  exemple.  Ce  calcul  ayant  déjà  été  fait  dans  le  chapitre  de 
Statistique,  nous  savons  que  le  résultat  est  la  loi  de  Gauss-Laplace: 

(fc-//)2 

P(k,  ju,<j)  =  — -j=  e  lcjl 

Équation  17  Loi  de  Gauss-Laplace 

Ainsi,  dans  notre  exemple,  nous  avons  p  =  1  et  l'écart-type  est  donné  par  l'estimateur  sans 
biais  de  l'écart-type  (voir  mon  livre  de  Mathématiques  Appliquées): 


g  = 


É(a  -  a)2 


Équation  18  ESB 


ce  qui  dans  notre  exemple  donne  a  =  1 . 

Pour  calculer  la  probabilité  nous  calculons  la  valeur  numérique  de  la  loi  de  Gauss-Laplace 
pour  k  =0,g  =  l,p  =  1: 

!  M  l  _i 

P(0,1,1)  = - = e  212  =^=e  2  =0.2419  =  24.19% 

1-V2  n  \I27t 

Ainsi,  en  appliquant  la  loi  normale  nous  avons  24.19%  de  chance  d'avoir  0  éléments 
défectueux  sur  8.  Cet  écart  par  rapport  aux  autres  méthodes  s'expliquant  simplement  par  les 
hypothèses  de  départ  (nombre  d'échantillons  fini,  probabilité  faible,  etc.) 

Remarque:  Ceux  qui  penseraient  utiliser  la  loi  triangulaire  (voir  mon  livre  de  Mathématiques 
Appliquées)  doivent  tout  de  suite  l'oublier.  Effectivement,  comme  en  qualité  la  valeur 
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optimiste  sera  le  zéro  par  définition,  la  probabilité  que  le  nombre  de  défauts  soit  égal  à  0  sera 
immédiatement  de  zéro. 

Comme  le  signale  très  justement  Philip  Bayard  Crosby  (considéré  avec  Deming  comme  un 
des  initiateurs  de  la  démarche  qualité  et  inventeur  du  concept  "zéro  défauts"): 

«Nous  sommes  tous  habitués  à  admettre  que  l'erreur  est  inévitable.  Non  seulement,  nous  en 
acceptons  l'idée,  mais  nous  nous  attendons  à  ce  qu'elle  se  produise.  Lorsque  nous  concevons 
un  circuit  imprimé,  programmons  un  ordinateur,  soudons  des  joints,  tapons  une  lettre  à  la 
machine...  nous  acceptons  l'idée,  sans  que  cela  nous  dérange  de  commettre  quelques  erreurs 
et  la  direction  de  l'entreprise  en  tient  compte  dans  la  formulation  de  ses  plans...  Pourtant,  il 
faut  bien  admettre  que  nous  n  'avons  pas  les  mêmes  critères  de  comportement  dans  notre  vie 
privée.  Si  tel  était  le  cas,  il  faudrait  nous  résigner,  de  temps  à  autre,  à  ne  pas  recevoir  notre 
dû  quand  nous  allons  encaisser  un  chèque.  On  trouverait  normal  que,  de  temps  à  autre,  une 
infirmière  laisse  tomber  un  bébé  qui  vient  de  naître...  Seulement  voilà,  en  tant  qu’ individu, 
nous  ne  tolérons  pas  ce  genre  de  chose.  Nous  avons  donc  deux  types  de  critères  de 
comportement  :  les  uns  pour  notre  travail,  les  autres  pour  notre  vie  privée.  Cette  différence 
d'attitude  s'explique  par  le  fait  que  l'environnement  familial  impose  des  contraintes  plus 
strictes  que  l'environnement  professionnel.  En  bref,  il  nous  faut  déterminer  si  nous,  les 
cadres,  formulons  clairement  les  instructions  données  à  ceux  qui  comptent  sur  nous  pour  les 
guider  et  les  orienter.  Nous  devons  donc  formuler  une  norme  qui  définisse,  d'une  manière 
claire  et  constante,  quel  est  le  niveau  de  qualité  requis  »  (P.  B.  Crosby,  La  qualité,  c'est 
gratuit,  l’art  et  la  manière  d’obtenir  la  qualité,  Economica,  1986,  313  p.  1986,  p.  174). 

L'idée  de  zéro  défaut  peut  apparaître  également  comme  la  conséquence  d'une  division  du 
travail  développée  pour  des  produits  complexes.  En  effet,  pour  des  productions  en  série  de 
produits  complexes,  quand  on  applique  des  pourcentages  de  défauts  de  l'ordre  de  0.1%  ou  1%, 
la  qualité  qui  en  résulte  est  médiocre.  B.  Lamotte  (B.  Lamotte  ,  La  maîtrise  de  la  qualité  :  des 
cercles  à  la  qualité  totale  dans  les  stratégies,d'entreprises  face  aux  ressources  Humaines. 
L'après-Taylorisme,  Economica,  Paris,  1988)  propose  à  ce  sujet  un  exemple  tout  à  fait 
éclairant: 

«Considérons  que  le  montage  d'une  voiture  de  tourisme  comprend  2' 500  opérations  et  que 
chaque  opération  est  parfaite  99  fois  sur  100.  A  priori,  réussir  une  opération  dans  99  %  des 
cas  est  le  signe  d'une  maîtrise  quasi  parfaite  de  la  qualité.  Mais  en  fait,  la  perfection  de 
l'ensemble  suppose  que  2'500fois  de  suite,  les  opérations  soient  parfaitement  réalisées.  Si  la 
production  quotidienne  se  monte  à  2 '000  unités,  sur  les  5  millions  d'opérations  effectuées 
quotidiennement  dans  notre  usine,  il  y  a  1%  de  défauts  de  montage  soit  50'000,  et  en  moyenne 
25  défauts  par  voiture,  ce  qui  est  difficilement  acceptable.  Aussi,  admettons  que  cette  usine 
imaginaire  soit  dotée  d'un  service  de  contrôle  intervenant  à  la  fin  du  montage  de  façon 
systématique.  Cela  représente  un  coût  considérable  en  heures  de  travail  de  contrôle.  Si  les 
défauts  peuvent  être  corrigés,  il  faudra  faire  des  retouches,  remplacer  des  pièces  peut-être,  et 
travailler  dans  des  conditions  imprévues  pour  corriger  les  défauts.  S'ils  sont  trop  importants, 
ces  défauts  rendent  les  produits  inutilisables,  et  les  rebuts  sont  extrêmement  coûteux.  Pire 
encore,  si  le  service  de  contrôle  ne  voit  «  que  »  99  %  des  défauts,  il  en  subsiste  500 
quotidiennement,  et  cela  suppose  des  retours  et  réparations  coûteuses  ainsi  qu'une 
détérioration  de  l'image  de  marque  selon  les  performances  de  la  concurrence». 
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8. 6.4. 6.4  Indices  de  performance  et  de  contrôle  qualité 


Six  Sigma  défini  deux  indices  permettant  de  mesurer  pendant  le  processus  de  fabrication  la 
capacité  de  contrôle  dans  le  cas  d'un  grand  nombre  de  mesures  de  défauts  répartis  selon  une 
loi  de  Gauss-Laplace  centrée  autour  de  la  moyenne  (soit  une  loi  normale). 

Dl.  Nous  appelons  "indice  de  capacité  potentiel  de  contrôle"  (Potentiel  Process  Capability 
Index)  le  rapport  entre  l'étendue  de  contrôle  de  la  distribution  des  valeurs  et  la  qualité  de  Six 
Sigma  tel  que: 


C, 


E_ 

6(7 


ce  qui  s'écrit  aussi: 


C„ 


USL-LSL 

6cr 


Équation  19  Cp 


où  USL  est  la  limite  supérieure  de  contrôle  (Upper  Spécification  Control)  de  la  distribution  et 
LSL  la  limite  inférieure  (Lower  Spécification  Control)  que  nous  imposons  fréquemment 
comme  à  distances  égales  par  rapport  à  la  moyenne  ^  . 

Bien  évidemment,  la  valeur  G  de  l'écart-type  peut-être  doit  être  calculée  en  utilisant  les 
estimateurs  de  maximum  de  vraisemblance  ou  sans  biais  vue  dans  le  chapitre  de  statistiques. 

Normalement,  au  sein  des  entreprise,  l'étendue  de  contrôle  est  fixe  (le  numérateur)  et  donc 
quand  la  valeur  de  l'écart-type  type  est  grande  (plus  de  variations,  moins  de  contrôles)  la 
valeur  de  l'indice  est  faible  et  lorsque  l'écart-type  est  faible  (moins  de  variation,  plus  de 
contrôles)  la  valeur  de  l'indice  est  élevé. 

Comme  le  montre  les  deux  exemples  ci-dessous: 


-*■ 


3ü 


> 


*■ 


LSL  il  USL  LSL  |i  USL 


(a)  Cp  =  ] 


(b)  Cp-  2 


C 

L'indice  p  impose  que  la  moyenne  (l'objectif)  est  centrée  entre  LSL  et  USL.  Dès  lors,  la 
moyenne  est  confondue  avec  ce  que  nous  appelons  la  "cible"  T  du  processus. 
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Mais  la  moyenne  ^  dans  la  réalité  peut  être  décalée  par  rapport  à  l’objectif  T  initial  qui  doit 
lui  toujours  être  à  distance  égale  entre  USL  et  LSL  comme  le  montre  la  figure  ci-dessous: 


SIX  SIGMA  CAPABILITY 


LSL 


T 


USL 


+1  Voix  du  client 
|  [étendue) 


Voix  du  processus 
!  [six  sigma) 


Limite  de  toiélance 
±50% 


iqü%  -sü% 


2C%  4Ü%  .60%  60%  100% 


Variation  de^  délsis/çputs  en  %  de  U  pl^nrfïçætion  initiale 


Mais  n'est  pas  forcément  le  cas  dans  la  réalité  où  les  ingénieurs  (quel  que  soit  leur  domaine 
d'application)  peuvent  choisir  des  LSL  et  USL  asymétriques  par  rapport  à  la  moyenne.  D'où  la 
définition  suivante: 

D2.  Nous  appelons  alors  "indice  de  capabilité  de  contrôle"  (Process  Capability  Index)  la 
relation: 


cpk=cpa-k) 


Équation  20  Cpk 


avec: 


\t-m\  \t-m\ 

^  (USL  -  LSL)  3crCP 


où  ^  -  0  est  appelé  le  "degré  de  biais"  et  T  le  "target". 


Au  fait  cet  indicateur  peut  sembler  très  artificiel  mais  il  ne  l'est  pas  totalement.  Effectivement 
il  y  a  quelques  valeurs  remarquables  qui  permettent  de  se  faire  une  bonne  idée  ce  qu'il  se 
passe  avec  cet  indicateur  (et  c'est  le  but  de  celui-ci): 

1.  Si  la  moyenne  et  la  cible  sont  confondues  nous  avons: 


2.  Si  faute  d'un  mauvais  contrôle  du  processus  nous  avons: 
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\T -ju\>  0.5 -(USL-LSL) 


alors  la  moyenne  P  est  soit  au-dessus  de  USL  ou  en  dessous  de  LSL  ce  qui  a  pour 

C  <0 

conséquence  d'avoir  ^  > 1  et  donc  pk  .  Le  fait  que  l'indice  soit  négatif  met  bien  en 
évidence  la  mauvaise  maîtrise  du  processus. 

3.  Si  nous  avons: 


0  <  \T  -  ju\  <  0.5  •  (USL  -  LSL ) 

alors  la  moyenne  P  est  comprise  entre  les  valeurs  USL  et  LSL  ce  qui  a  pour  conséquence 
d'avoir  0  <  k  <  1  et  donc  ^  <  ^pk  <  . 

4.  Si  nous  avons: 

\T-ju\  =  0.5  (USL -LSL) 

alors  cela  signifie  simplement  que  la  moyenne  est  confondue  avec  USL  ou  LSL  et  nous  avons 
alors  k  = 1  et  ^  pk  ~  ^ 

Par  ailleurs,  Six  Sigma  rajoute  la  définition  suivante  (qui  est  logique. . .)  dans  le  cas  particulier 
où  l'étendue  n'est  pas  bornée,  c'est-à-dire  que  seulement  USL  ou  LSL  sont  définis  mais  pas  les 
deux  en  même  temps. 

Ainsi,  nous  avons  le  "Upper  Capability  Index"  (CPU)  et  "Lower  Capability  Index  (CPL): 

USL  —  ll  u  —  LSL 

CPU  = - -  CPL  =  - - 

3(7  3(7 

Équation  21  CPU,  CPL 


et  l'interprétation  est  toujours  basée  sur  le  même  principe  que  l'indice  p  . 

8. 6.4.7  Bilans 

Dans  la  boucle  à  rétroaction  de  la  réalisation  du  projet  il  est  donc  important  de  faire  des  bilans 
d'avancement  pour  mener  les  actions  correctives  ad  hoc.  Il  est  bon  de  rappeler  les  points 
triviaux  que  l'on  peut  faire  si  on  a  du  temps  à  disposition  pendant  les  réunions  de  l'équipe  de 
projet: 

1.  Bilans  intermédiaires  et  de  fin  de  réalisation 

a.  Mesurer  les  écarts  par  rapport  aux  prévisions  initiales  pour  vérifier  si  les  jalons 
sont  respectés 

b.  Analyser  ces  écarts  et  en  trouver/expliquer/documenter  la  raison 

c.  Capitaliser  pour  les  futures  réalisations  pour  aider  à  la  prise  de  décision  pour 
de  futurs  projets 
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Bilans  d'exploitation 


a.  Mesurer  les  retours  opérationnels  et  financiers  obtenus  afin  de  vérifier  que  le 
projet  rapporte  bien  ce  pour  quoi  il  a  été  lancé  (notion  de  retour  sur 
investissement) 

b.  Comparer  à  l'étude  de  justification  (analyse  des  risques  en  cas  de  dérapage,  de 
non-respect  d'un  jalon...) 

c.  Capitaliser  pour  les  futures  réalisations 


Nous  voyons  ci-dessus  que  la  notion  de  mesure  revient  fréquemment.  Mais  comme  pour  les 
personnes  faisant  des  statistiques,  il  est  parfois  difficile  de  savoir  ce  qu'il  faut  mesurer.  À  cet 
effet,  la  méthode  ITIL  propose  un  sympathique  petit  schéma  que  je  me  suis  permis  de  leur 
emprunter  et  qui  résume  simplement  relativement  bien  les  choses: 


Un  gros  problème  que  l'on  peut  fréquemment  observer  (particulièrement  chez  les  consultants 
grands  cabinets  d'audit)  est  la  pléthore  de  graphiques.  Ces  derniers  sont  peut-être  très  jolis  à 
regarder,  mais  la  vraie  question  est:  "qu'est-ce  que  cela  signifie?". 

Il  m'arrive  fréquemment  de  faire  deux  remarques  aux  consultants: 

1.  Où  est  la  documentation  avec  les  conclusions  et  permettant  à  tout  audience  de  lire  ce 
graphique  sans  interprétation  hasardeuse? 

2.  Le  graphique  n'a  aucun  sens:  il  ne  respecte  ni  les  normes  et  n'a  aucune  utilité 
statistiquement  parlant. 

Souvent  la  deuxième  remarque  est  mal  acceptée  par  les  consultant  ou  employés  internes  mais 
c'est  normal...  pour  analyser  des  données  il  faut  être  un  ...  analyste  ...  et  cela  ne  s'apprend 
qu'après  de  longues  études  universitaires  en  statistiques  et  non  pas  simplement  en  faisant  une 
petite  formation  continue  en  gestion  de  projets  de  5  ou  10  jours. 
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Précisons  également  que  les  conclusions  du  type:  "Nous  pouvons  constater  une  baisse  du 
nombre  d'incidents  par  rapport  au  mois  précédent ..."  n'apporte  pas  d'explication 
complémentaire  ou  d'interprétation  aux  chiffres  bruts,  ce  qui  n'a  donc  aucun  intérêt  sauf  à 
alourdir  encore  plus  la  présentation  des  résultats. 


8.6.5  Terminaison  (clôture)  de  projet 

Si  on  se  préoccupait  de  l'achèvement  des  choses,  on  ne  ferait  jamais  rien 

François  1er 

«ÀM  Q  &  ® 

Project-End  Review: 

mppHnp  Lessons  Learned  Best  Practices  Administrative  Closure 

Le  but  de  la  clôture  du  projet  est  d'assurer  (comme  le  conseille  à  très  juste  titre  le  PMBOK): 

1 .  Qu'un  projet  est  terminé  de  façon  contrôlée  et  organisée 

2.  Récolter  les  feedback  pour  les  prochains  projets 

3.  Que  toutes  les  personnes  qui  y  sont  liées  ont  été  déchargées  de  leurs  responsabilités 

4.  De  s'assurer  que  tout  le  monde  retourne  au  travail  régulier  dans  de  bonnes  conditions 

5.  Qu'on  ait  félicité  tout  le  monde  pour  la  participation  et  pour  l'investissement 

6.  Que  le  mandant  évite  de  penser  que  le  support  après  réalisation  est  gratuit 

La  phase  finale  du  projet  est  donc  une  phase  d'acceptation,  par  le  client  du  produit  et/ou  du 
service  selon  le  but  et  les  objectifs  fixés  lors  de  l'identification.  Cette  étape  consiste 
principalement  à  utiliser  un  document  intitulé  "rapport  de  clôture"  ou  "rapport  de  revue  post¬ 
implémentation  (RPI)". 

Signalons  que  selon  le  PMI,  si  le  mandant  en  recevant  le  livrable  confirme  que  le  travail  a  été 
fait  mais  que  le  résultat  ne  lui  plait  pas,  ceci  n'a  rien  à  voir  alors  avec  le  projet  en  cours!  Soit 
le  mandant  fera  un  change  request,  soit  un  nouveau  projet  devra  être  initié. 

Ce  rapport  renferme  les  bonnes  et  les  mauvaises  expériences  relatives  au  projet  qui  sont 
consignées  dans  sa  base  de  données.  Donc,  advenant  un  autre  projet  similaire,  le  futur  gérant 
de  projet  pourra  s'inspirer  des  expériences  passées  afin  d'éviter  de  commettre  les  mêmes 
erreurs.  C'est  aussi  durant  cette  phase  qu'il  faut  relocaliser  son  personnel. 

Voici  les  questions  minimales  auxquelles  on  essaie  de  répondre  durant  la  phase  de 
terminaison  du  projet: 

■  A-t-on  respecté  l'échéancier  prévu? 

■  A-t-on  rencontré  le  budget  prévu? 
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■  A-t-on  utilisé  les  ressources  d'une  façon  efficace  et  efficiente? 

■  Quel  est  le  degré  d'atteinte  des  buts  et  objectifs? 

■  Avons-nous  mis  à  jour  les  processus  (adaptés  au  REX)? 

■  L'information  du  projet  a-t-elle  bien  été  sécurisée? 

■  Les  indicateurs  de  l'assurance  qualité  ont-ils  les  chiffres  définitifs? 

■  Tous  les  risques  et  anomalies  sont-ils  clos? 

■  L'équipe  marketing  de  projet  s'est-elle  bien  assurée  que  tout  le  monde  est  au  courant 
que  je  le  projet  est  terminé? 

Souvent,  les  dirigeants  effectuent  aussi  une  vérification  du  projet  afin  d'obtenir  une  opinion 
objective  sur  l'atteinte  des  objectifs.  Cette  vérification  permet  de  déterminer  la  façon  dont  le 
gérant  de  projet  a  administré  les  délais  (temps),  les  coûts  et  la  qualité  -  les  trois  prémisses 
essentielles  à  tout  projet  et/ou  produit  (ou  services)  qu'on  doit  livrer  au  client. 

Nous  venons  de  brosser  un  tableau  sommaire  sur  la  gestion  de  projet.  Nous  avons  décrit  le 
cycle  de  vie  d'un  projet  type  et  disséqué  ses  différentes  phases  ainsi  que  les  divers  outils 
relatifs  à  celles-ci.  Nous  avons  ensuite  commenté  les  facteurs  clés  du  succès  inhérent  à  une 
saine  gestion  de  projet.  Tout  cela  afin  de  mettre  en  lumière  l'extraordinaire  capacité  de  cette 
approche  de  gestion  et,  surtout  sa  très  grande  flexibilité. 

Nous  avons  aussi  examiné  le  mécanisme  de  contrôle  à  rétroaction,  qui  sert  à  évaluer  les  écarts 
entre  les  prévisions  et  les  résultats  obtenus.  Il  faut  établir  des  lignes  de  conduite  qu'on  doit 
essayer  de  suivre  pour  assurer  le  pilotage  efficace  du  projet.  Le  gérant  de  projet  doit  être  un 
motivateur  hors  pair  et  manifester  un  leadership  honnête  pour  bien  utiliser  les  ressources 
humaines  sous  sa  supervision. 

Exercice: 

Préparez  sur  une  feuille  les  réponses  aux  questions  suivantes.  Complétez  par  votre  expérience 
et  vos  hypothèses  personnelles  ce  qui  a  été  vu  précédemment. 

1 .  Qu'est-ce  que  la  gestion  par  projet? 

2.  Énumérez  les  différentes  phases  du  cycle  de  vie  d'un  projet. 

3.  Énumérez  les  études  de  faisabilité  qu'on  devrait  effectuer  avant  d'entreprendre  un  projet. 
Expliquez  brièvement  chacune  d'entre  elles 

4.  Énumérez  les  étapes  du  processus  de  planification  détaillée  d'un  projet. 

5.  Énumérez  les  différents  facteurs  de  succès  vitaux  à  une  saine  gestion  de  projet. 

6.  Donnez  des  exemples  de  projets. 

7.  Expliquez  le  mécanisme  de  contrôle  à  rétroaction.  Que  doit-on  contrôler  dans  un  projet? 
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8.  Dans  quel  but  évalue-t-on  les  résultats  du  projet?  Énumérez  des  exemples  de  rapports  qui 
aideront  le  gérant  de  projet  à  évaluer  ses  subordonnés. 


9.  Quels  aspects  de  la  gestion  de  projet  peuvent  impliquer  un  certain  niveau  d'incertitude? 
Pourquoi? 


10.  Définir:  étendue,  horaire,  coût  et  satisfaction  du  consommateur  et  pourquoi  ils  sont 
considérés  comme  des  contraintes? 


1 1 .  Pourquoi  est-il  important  de  satisfaire  le  consommateur? 

12.  Nommez  et  décrivez  les  étapes  requises  afin  de  développer  un  plan  de  base. 

13.  Pour  quelle  raison  un  coordinateur  du  projet  doit-il  contrôler  l'évolution  d'un  projet? 

14.  Pensez  à  un  projet  dans  lequel  vous  êtes  présentement  impliqué  ou  dans  lequel  vous  étiez 
impliqué  et: 

a.  Décrivez  les  objectifs,  l'étendue  l'horaire,  le  coût  ainsi  que  toute  hypothèse  faite. 

b.  Où  en  êtes-vous  dans  la  vie  du  projet? 

c.  Est-ce  que  ce  projet  possède  un  plan  de  base?  Si  oui,  décrivez-le,  sinon,  créez-le. 

d.  Est-ce  que  quelqu'un  est  en  charge  de  contrôler  l'évolution  de  ce  projet?  Si  oui, 
comment?  Si  non,  pourriez-vous  le  faire? 

e.  Décrivez  une  circonstance  inattendue  qui  pourrait  mettre  en  péril  le  succès  du  projet. 

f.  Décrivez  les  avantages  anticipés  du  projet. 

g.  Énumérez  les  risques  potentiels  (manque  de  ressources  monétaire;  incompétences  du 
coordinateur  de  projet,  etc.)  qui  pourraient  affecter  la  réalisation  du  projet. 
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9.  Vente  d'un  projet 

Un  point  très  souvent  omis  dans  les  ouvrages  de  gestion  de  projets  est  la  "vente  d'un  projet". 
Or,  dans  la  réalité  de  nombreux  inventeurs,  responsables,  ingénieurs  ou  scientifiques  doivent 
parfois  vendre  l'idée  d'un  projet  à  un  potentiel  investisseur,  un  client  ou  un  responsable 
interne.  La  même  approche  s'applique  quand  il  s'agit  de  motiver  une  équipe  en  vendant  l'idée 
du  projet  et  les  bénéfices  qui  y  sont  associés.  Il  convient  donc  de  nous  y  attarder  un  petit  ne 
serait-ce  qu'un  bref  instant. 

Remarque:  Il  faut  savoir  que  de  nombreux  responsables  de  projets  doivent  s'improviser  aussi 
vendeur  de  projets  au  début  de  leur  carrière  et  dans  des  petites  structures  de  moins  de  100  à 
200  employés.  Objectivement  la  vente  est  un  métier  et  je  recommande  fortement  une 
formation  d'au  minimum  de  5  jours  avec  une  spécialiste  du  domaine  afin  que  vous  appreniez 
les  pièges  et  manipulations  dans  lesquels  des  interlocuteurs  peuvent  vous  amener  sans  que 
vous  vous  en  rendiez  compte. 

Avant  de  commencer  présenter  le  quadripôle  du  domaine  de  la  vente: 


Ainsi,  un  responsable  de  projet  qui  néglige  l'un  des  pôles  ne  parviendra  pas  à  exploiter 
pleinement  tout  le  potentiel  d'une  démarche  de  vente.  Il  décevra  ses  interlocuteurs  qui  exigent 
d'un  responsable  de  projet  un  certain  niveau  de  compétence. 

9.1  Dix  commandements 

Pour  vendre  correctement  l'idée  d'un  projet  on  peut  se  rappeler  d'un  ensemble  de  dix 
commandements  outre  le  fait  que  le  projet  doit  vraiment  être  à  la  pointe  de  l'innovation  pour 
en  valoir  la  peine. 

Le  premier  ensemble  de  10  commandements  est  celui  des  techniques  de  vente: 

1.  Déterminez  la  pertinence  de  votre  projet  et  les  besoins  actuels  de  vos  interlocuteurs 
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2.  Préparez-vous  avant  de  présenter  votre  projet 

3.  Faites  une  bonne  impression 

4.  Investissez-vous  pleinement  dans  chacune  de  vos  présentations 

5.  Tenez  compte  des  objections  de  vos  interlocuteurs 

6.  Confirmez  toutes  les  informations 

7.  Demandez  à  vos  interlocuteurs  de  prendre  une  décision 

8.  Utilisez  un  vocabulaire  adapté  à  vos  interlocuteurs 

9.  Cherchez  sans  cesse  à  progresser 

10.  Soyez  un  produit  de  votre  produit 

Le  deuxième  ensemble  de  10  commandements  est  celui  de  l'art  de  la  vente: 

1.  Soyez  avide  de  faire  des  découvertes  dans  le  domaine  de  communication  de  la  vente 

2.  Ayez  des  attentes  réalistes 

3.  Soyez  ouvert  au  changement 

4.  Répétez,  pratiquez  et  analysez  vos  techniques  de  ventes 

5.  Personnalisez  vos  techniques  de  ventes  (informez-vous  sur  vos  interlocuteurs51) 

6.  Soyez  discipliné 

7.  Evaluez  vos  résultats  et  gardez-en  une  trace 

8.  Tenez  un  journal  de  vos  entretiens 

9.  Traitez  vos  interlocuteurs  avec  respect  et  empathie  et  souvenez-vous  de  leur  nom! 

10.  Impliquez-vous  personnellement 

Le  troisième  ensemble  de  10  commandements  est  celui  de  la  politesse  est  du  savoir  vivre: 

1.  Saluez  vos  interlocuteurs 

2.  Soyez  toujours  courtois  (s'il  vous  plaît,  merci) 

3.  Exprimez  votre  gratitude  pour  que  vos  interlocuteurs  aient  accepté  de  vous  rencontrer 

4.  Appelez  vos  interlocuteurs  par  leur  nom 

5.  Présentez-vous  rapidement 

6.  Laissez  vos  interlocuteurs  finir  leurs  phrases 

7.  Ayez  une  grande  empathie  vis-à-vis  de  vos  interlocuteurs 

8.  Avoir  une  attitude  si  possible  toujours  positive 

9.  Soyez  détendu  et  naturel 

10.  Choisissez  soigneusement  votre  tenue 

Le  quatrième  ensemble  de  10  commandements  est  celui  des  qualités  d'un  bon  vendeur: 

1 .  Être  motivé  à  faire  ses  preuves 

2.  Être  sincère  et  ne  jamais  mentir 

3.  Avoir  une  grande  assurance 

4.  Avoir  une  grande  empathie  vis-à-vis  de  ses  interlocuteurs 

5.  Être  cohérent  avec  les  objectifs  définis  (ne  pas  se  disperser) 

6.  Avoir  une  aptitude  à  respecter  un  planning 

7.  Avoir  un  enthousiasme  inébranlable  (positiver  le  négatif) 

8.  Avoir  une  attitude  si  possible  toujours  positive 

9.  Donner  la  priorité  à  l'aspect  humain  dans  le  cas  d'une  action  de  vente 


51  Visitez  leur  profil  web,  la  page  web  de  leur  société,  googlez  leur  nom,  procurez-vous  des  catalogues  sur  les 
produits  de  leur  entreprise,  consultez  l'état  financier  de  la  société  si  disponible,  etc. 
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10.  Avoir  soif  d'apprendre  et  donc  d'écouter 
Le  cinquième  ensemble  de  10  commandements  est  celui  de  la  connaissance  du  sujet: 

1.  Connaître  les  buts  et  objectifs  de  votre  projet 

2.  Connaître  le  nom  des  jalons  et  phases  du  projet 

3.  Connaître  les  avantages  apportés  par  votre  projet 

4.  Connaître  les  détails  techniques  et  financiers  de  votre  projet 

5.  Connaître  les  fonctionnalités  du  produit  final  de  votre  projet 

6.  Connaître  les  différents  scénarios  d'avancement  de  votre  projet 

7.  Connaître  l'investissement  que  le  projet  représente  pour  vos  interlocuteurs 

8.  Préparer  un  modèle  d'investissement  pour  vos  investisseurs 

9.  Avoir  connaissance  de  projets  éventuellement  concurrents  (veille  concurentielle) 

10.  Essayer  de  ne  jamais  montrer  que  vous  ne  savez  pas  quelque  chose  sur  votre  projet 

Pour  clore  ce  petit  chapitre  sur  les  dix  commandements  il  est  important  de  noter  que  certains 
interlocuteurs  sont  de  plus  en  plus  à  l'aise  avec  les  technologies  de  l'information  (Internet, 
Ordinateur  Portable,  iPad).  Vous  avez  donc  intérêt  à  maîtriser  votre  sujet  suffisamment  quand 
vous  vous  retrouvez  face  à  ce  type  d'individus  car  ils  n'hésiteront  pas  à  contrôler  l'information 
pendant  l'instant  même  où  vous  la  présentez.  Ceci  est  particulièrement  vrai  quand  vous  être 
dans  des  entreprises  d'ingénierie  ou  de  haute  technologie  ou  que  vos  interlocuteurs  sont  des 
hauts  potentiels. 

9.2  Démarchage 

Si  vous  devez  vendre  (dans  le  sens  propre  ou  figuré  du  terme)  un  projet,  n'entamez  jamais  une 
démarche  sans  avoir  envisagé  la  situation  du  point  de  vue  des  interlocuteurs.  Mettez-vous  à 
leur  place  et  réfléchissez  à  ce  qui  vous  pousserait  à  sacrifier  un  peu  de  votre  temps  pour  lire 
un  courrier  ou  prendre  un  appel  ou  agender  une  réunion.  Si  aucune  des  réponses  qui  vous 
viennent  à  l'esprit  (utilité,  retour  sur  investissement,  coup  de  cœur,  image. . .)  ne  vous  semble 
satisfaisante,  il  est  probable  que  les  informations  dont  vous  disposez  sur  le  projet  sont 
insuffisantes  ou  alors  vous  ne  connaissez  pas  assez  vos  interlocuteurs  pour  leur  présenter  le 
projet.  Si  tel  est  le  cas,  il  est  temps  de  plancher  de  nouveau  sur  votre  sujet. 

Il  est  possible  que  vous  deviez  adopter  des  méthodes  un  peu  originales  pour  vous  démarquer 
ou  obtenir  une  réponse  positive  d'entretien  ou  une  réponse  tout  court....  Voici  quelques  pistes 
éventuelles: 

•  Proposez  directement  des  dates  de  rencontre 

•  Joignez  une  photographie  à  vos  e-mails  ou  à  votre  documentation 

•  Joignez  une  bande  dessinée  illustrant  un  ou  des  situations 

•  Choisissez  un  style  vestimentaire  professionnel  et  original  à  la  fois 

•  Ajoutez  des  citations  à  la  fin  de  vos  documentations 

•  Créez  des  cartes  de  visites  originales  (à  thèmes  ou  avec  une  autre  couleur  que  le  blanc) 

•  Proposez  un  plan  d'investissement  adapté  gratuitement 

•  et  autres  en  fonction  de  vos  idées. . . 

Lorsque  vous  obtenez  un  rendez-vous  avec  des  interlocuteurs  intéressés  récapitulez  tous  les 
détails  et  demandez  s'il  y  a  des  particularités  à  savoir  concernant  la  manière  de  vous  rendre  au 
lieu  de  rendez-vous  (travaux,  détournements,  neige,  etc.).  S'il  y  a  plusieurs  interlocuteurs 
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différents,  essayez  de  vous  renseigner  ou  de  deviner  qui  est  le  véritable  décideur  (la  bonne 
personne)  !  Demandez  aussi  bien  l'orthographe  et  la  prononciation  des  noms  et  prénoms  de 
vos  interlocuteurs. 

Remarque:  Si  vous  êtes  passé  par  un(e)  réceptionniste  prenez  le  temps  de  lui  envoyer  un  e- 
mail  de  remerciements  pour  son  professionnalisme.  Votre  gratitude  vous  ouvrira  peut-être  des 
portes.  Si  vous  avez  de  bonnes  relations  avec  le  ou  la  réceptionniste,  celui-ci  ou  celle-ci  sera 
heureux  de  vous  revoir  et  vous  accueillera  avec  plaisir.  Il  ou  elle  vous  protégera  peut-être 
même  contre  vos  propres  concurrents. 

Si  vos  interlocuteurs  lors  d'une  réunion  ne  prennent  pas  le  stylo  pour  valider  un  projet, 
n'exercez  aucune  pression  pour  obtenir  ce  que  vous  voulez.  Il  suffit  parfois  de  dire:  "Quand 
commençons-nous?"  et  cela  aura  parfois  tendance  à  leur  forcer  un  peu  la  main. . . 

9.3  Profils 

Quand  vous  aurez  à  vendre  un  projet  (idée)  vous  allez  vous  confronter  à  une  grande  gamme 
de  comportements/profils  humains.  Vous  pouvez  déjà  vous  référer  à  la  page  184  pour  avoir 
une  première  typologie. 

Dans  le  cas  plus  spécifique  de  la  défense/vente  d'un  projet  vous  aurez  typiquement: 

•  Les  fidèles:  Vous  avez  déjà  effectué  plusieurs  projets  avec  succès  avec  eux  et  ils 
connaissent  votre  professionnalisme.  Si  vous  ne  parvenez  pas  à  les  convaincre  ils 
demanderont  probablement  juste  quelques  modifications  ou  diront  que  ce  sera  peut- 
être  pour  une  autre  fois. . . 

•  Les  combinards:  Type  d'interlocuteurs  qui  n'acceptent  rien  tant  qu'ils  ne  sont  pas 
convaincus  et  qu'ils  n'obtiennent  pas  quelque  chose  immédiatement  en  échange.  C'est 
probablement  la  typologie  la  plus  fréquente.  Il  faut  dans  cette  situation  prévoir  un 
geste  possible  sans  qu'il  fasse  trop  augmenter  le  risque  du  projet  de  manière 
inconsidérée  et  tout  en  restant  la  légalité. 

•  Les  responsables:  Ce  sont  des  interlocuteurs  souvent  occupés  et  ayant  peu  de  temps, 
il  faut  donc  aller  à  l'essentiel  et  les  surprendre  par  votre  concision  (s'en  tenir  aux 
chiffres  et  faits).  Vous  aurez  beaucoup  de  peine  à  rencontrer  plusieurs  un  même 
interlocuteur  de  ce  type  il  faut  donc  être  très  professionnel  car  vous  serez  jugé  du 
début  à  la  fin  de  votre  discours. 

•  Les  indécis:  Il  faut  être  patient  avec  ce  type  d'interlocuteur  et  leur  laisser  le  temps  de 
la  réflexion.  Il  faut  idéalement  demander  quand  est-ce  que  vous  pourrez  les  contacter 
pour  connaître  leur  décision  en  précisant  bien  que  cela  ne  presse  pas. 

•  Les  rabat-joie:  Ils  ont  toujours  quelque  chose  à  redire  sur  vos  projets.  Il  faut  prendre 
ces  critiques  comme  une  bonne  volonté  (car  c'est  souvent  le  cas)  et  donc  bien  faire 
comprendre  que  vous  allez  les  analyser  car  elles  sont  intéressantes.  A  force  de  leur 
dire  que  leurs  propositions  (critiques)  sont  intéressantes,  ils  vont  se  sentir  impliqués 
dans  le  projet  et  peuvent  alors  avoir  une  opinion  favorable  sur  ce  dernier. 

•  Les  méthodiques:  Ce  sont  des  interlocuteurs  qui  vont  vérifier  que  vous  respectez  des 
normes,  processus  que  tout  est  bien  analysé  et  structuré  et  qu'un  procès-verbal  sera 
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bien  rédigé  à  la  fin  de  la  rencontre.  Vous  avez  intérêt  avant  et  après  la  rencontre  de 
montrer  via  l'envoi  de  e-mails  que  vous  êtes  organisé  (plan  de  la  réunion,  compte 
rendu  de  la  réunion  ou  autres. . .). 

•  Les  dominateurs:  Ce  sont  des  interlocuteurs  qui  seront  avec  vous  juste  pour  se  donner 
de  l'importance  au  sein  de  leur  entreprise.  On  les  reconnaît  car  souvent  ils  ne  savent 
pas  ce  qu'ils  veulent  et  ne  comprennent  rien  à  ce  que  vous  leurs  proposez  (ils  ne 
comprennent  souvent  pas  leur  propre  travail. . .).  Il  faut  les  flatter  un  peu. 

•  Les  dictateurs:  Il  faut  faire  les  choses  à  leur  façon  ou  ne  pas  les  faire  du  tout.  Ils 
s'autoproclament  spécialistes  dans  tous  les  domaines  que  vous  leur  présentez  (attention 
parfois  c'est  le  cas!  !  !).  Ils  peuvent  faire  preuve  de  ce  que  beaucoup  prendront  pour  de 
l'impolitesse  (au  fait  ils  veulent  juste  être  brefs)  et  vont  souvent  vous  interrompre 
(souvent  parce  qu'ils  bouillonnent  d'idées).  Vous  devez  être  à  l'écoute  et  les  laisser 
parler  jusqu'à  ce  qu'ils  aient  dit  ce  qu'ils  avaient  à  dire.  Il  faudra  par  contre  prévoir  un 
autre  rendez-vous  mais  en  insistant  sur  le  fait  que  c'est  pour  continuer  ces  échanges  à 
forte  valeur  ajoutée. 

•  Les  cyniques:  Ce  sont  ceux  qui  ne  voient  pas  l'intérêt  du  changement  et  de 
l'innovation.  Il  faut  alors  leur  donner  des  contre-exemples  fameux  de  l'utilité  de  votre 
projet  ou  de  projets  similaires  dont  tous  les  médias  (sérieux  et  connus)  ont  parlé. 


9.4  Discours 


De  nombreux  termes  ou  expressions  couramment  utilisés  dans  la  communication  verbale 
peuvent  faire  naître  des  images  négatives,  des  craintes  ou  l'inverse. 

Remarque:  Il  faut  absolument  éviter  d'utiliser  du  jargon  courant  de  la  rue  de  tous  les  jours 
ainsi  que  du  jargon  technique  avec  des  abréviations  à  n'en  plus  finir.  Et  n'oubliez  pas  aussi 
d'écouter  deux  fois  plus  vos  interlocuteurs  que  vous  ne  parlez. 


9.4.1  Termes  à  éviter/utiliser 


Donc  voici  d'abord  une  liste  non  exhaustive  de  termes  à  remplacer: 
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Au  lieu  de... 

Utiliser 

Vendre 

Susciter  l'intérêt  ou  aide  à  acquérir 

Il  faut 

Il  serait  préférable 

Je  suis  embêté 

Je  suis  emprunté 

Contrat 

Document,  accord  ou  formulaire 

Coût  ou  prix 

Investissement  ou  monant 

Processus 

Démarche  qualité 

Acompte 

Investissement  initial  ou  montant  initial 

Paiement  mensuel 

Investissement  mensuel  ou  montant  mensuel 

Acheter 

Acquérir 

Affaire 

Occastion  ou  transaction 

Objection 

Préoccupation 

Difficulté 

Défi 

Vanter 

Présenter  ou  montrer 

Commission 

Honoraire 

Réglementation 

Cadre  général 

Rendez-vous 

Visite 

Signer 

Approuve 

et  voici  encore  une  liste  exhaustive  de  termes  qui  font  toujours  bien  à  placer  dans  une 
discussion  avec  des  interlocuteurs  (il  y  en  plein  d'autres  dans  les  dictionnaire. . 

Innovant,  Discernement,  Partenariat,  Conciliation,  Acteur,  Diagnostic  partagé,  Faute  de  quoi. 
Développement,  Rétroaction,  Référentiel,  Point  de  vue,  Plan,  Cohésion,  Retenue,  Périphérie, 
Delta-neutre,  Je  suis  tout  à  fait  d'accord  avec  l'intervenant  précédent. . .,  Notion  essentielle,  Au 
fond,  on  peut  se  demander  si. . .,  Est-ce  que  ce  ne  serait  pas  plus  simplement  et  plus 
profondément. . .,  J'aimerais  revenir  dans  le  temps  qui  m'est  imparti. . .,  Antéprécédent(e), 
Prospective,  Synergie,  Convergence,  Stratégie  associative,  Une  dimension  stratégique...,  Un 
portefeuille  de  solutions...,  Proximité,  Lien  de  confiance,  Solidaires,  Il  s'agit  d'un  paradigme, 
Un  choix  dogmatique,  à  outrance,. . . 

9.4.2  Phrases  types 

Si  vos  interlocuteurs  ont  le  sentiment  que  vous  n'êtes  pas  sur  la  même  longueur  d'onde, 
présentez-leur  les  choses  de  la  manière  suivante: 


Messieurs  (Mesdames),  lorsque  je  ne  conseille  pas  les  autres  à 
adopter  l'une  de  mes  solutions,  je  suis  un  mandant,  comme  vous,  qui 
recherche  la  meilleure  solution  au  meilleur  prix.  Lorsque  je  fais  mes 
appels  d'offre,  j'espère  toujours  trouver  une  personne  susceptible  de 
me  parler  de  la  solution  qui  m'intéresse  afin  que  je  puisse  prendre  une 
décision  éclairée.  Aujourd'hui,  j'aimerais  que  vous  ayez  confiance  en 
mon  expertise.  N'hésitez  pas  à  me  poser  les  questions  qui  vous  passent 
par  la  tête. 


Veillez  à  ce  que  vos  interlocuteurs  ne  vous  entraînent  pas  dans  une  conversation  sur  un  sujet 
qui  pourrait  porter  à  polémique.  Certaines  personnes  le  font  uniquement  pour  vous  tester. 
Évitez-vous  aussi  d'aborder  des  sujets  comme:  la  religion,  la  politique,  les  compétences  des 
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individus,  la  qualité  de  la  gestion,  les  conflits  internes,  etc.  Si  vous  vous  trouvez  sur  un  terrain 
glissant,  éludez  le  sujet  de  la  manière  suivante: 


Je  passe  tellement  de  temps  sur  mes  projets  que  je  n'ai  pas  vraiment 
pu  suivre  cette  affaire.  Mais  vous  qu'en  pensez-vous? 


Si  on  vous  fait  comprendre  que  vous  êtes  trop  cher  par  rapport  à  la  concurrence  vous  pouvez 
dire: 


Je  comprends  que  vous  soyez  préoccupé  par  le  prix.  Vous  savez,  mon 
expérience  m'a  permis  de  comprendre  que  nous  recherchons  tous  à  la 
fois  la  meilleure  qualité,  le  meilleur  service  et,  bien  sûr,  le  meilleur 
prix.  Or,  aucune  société  à  ma  connaissance  ne  peut  offrir  les  trois  à 
un  niveau  très  pointu.  Pour  votre  confort  à  long  terme,  sur  lequel  de 
ces  trois  éléments  serviez-vous  prêt  à  faire  des  concessions:  la  qualité, 
le  service  ou  le  prix? 


ou  encore: 


Vous  savez  j'aurais  pu  travailler  pour  n'importe  quelle  société  dans 
mon  secteur.  Mais  j'ai  choisi  celle-ci  parce  que  je  voulais  pouvoir 
regarder  mes  interlocuteurs  en  face  et  leur  dire:  "Vous  avez  affaire  à 
la  société  la  plus  sérieuse  du  secteur.  "?  Je  sais  que  vous  recherchez  la 
qualité.  Pensez-vous  que  vous  regretterez  l’argent  que  vous  allez 
investir  pour  bénéficier  de  cette  qualité. 


Enfin,  si  vous  en  concluez  pas  dès  le  premier  rendez-vous,  laissez  la  porte  ouverte  à  une 
reprise  de  contact: 


Messieurs  (Mesdames),  je  vois  que  ma  solution  ne  semble  pas  vous 
convenir  à  ce  jour  mais  puis-je  me  permettre  de  rester  en  contact  avec 
vous  au  cas  où  l'évolution  du  projet  correspondrait  à  vos  attentes? 


9.5  Synergologie 

La  synergologie  est  l'art  d'interpréter  la  gestuelle  et  quand  vous  allez  vendre  un  projet  ou  que 
vous  faites  une  réunion  certaines  choses  sont  à  éviter  car  elles  peuvent  être  interprétées  à  tort 
ou  à  raison  par  des  personnes  n'ayant  pas  de  connaissances  scientifiques: 

•  Avoir  le  regard  fixe  et  vide  est  considéré  comme  négatif  (vous  êtes  ailleurs) 

•  Croiser  les  jambes  sous  la  table  de  réunion  quand  vous  êtes  assis  est  considéré  comme 
négatif  (geste  barrière) 

•  Croiser  les  bras  est  considéré  aussi  comme  négatif  (geste  barrière) 

•  Avoir  un  bras  refermé  et  détendu  vers  son  torse  et  l'autre  ouvert  vers  les  interlocuteurs 
est  considéré  comme  positif 

•  La  tête  légèrement  inclinée  vers  l'épaule  est  considéré  comme  positif 

•  Bouger  un  peu  les  épaules  est  considéré  comme  positif 

•  Bouger  un  peu  les  sourcils  est  considéré  comme  positif 

•  Bouger  trop  les  mains  est  considéré  comme  négatif  (stress) 
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•  Et  surtout  ne  vous  grattez  pas  où  que  ce  soit  car  dans  tous  les  cas  c'est  considéré 
comme  négatif 

9.6  Supports  visuels 

Quand  vous  allez  parler  de  votre  projet,  vos  interlocuteurs  auront  besoin  de  voir  pour  croire.  Il 
faut  donc  associer  des  images  aux  paroles.  Lors  de  votre  présentation,  les  supports  visuels 
vous  seront  donc  parfois  d'une  aide  précieuse. 

Vos  supports  doivent  s'articuler  autour  des  4  axes  suivants: 

•  Vous  et  votre  société 

•  Ce  que  vous  avez  fait 

•  Ce  que  vous  faites  pour  vos  clients 

•  La  plus-value  par  rapport  à  vos  concurrents 

Ces  4  axes  sont  incontournables.  S'ils  ne  font  pas  partie  de  vos  supports  visuels,  veillez  les 
intégrer  verbalement  dans  votre  présentation. 

En  ce  qui  concerne  l'utilisation  de  diapositives  prenez  surtout  garde  à: 

•  Faire  appel  à  un  graphiste  professionnel  pour  le  canevas  des  diapositives 

•  A  avoir  un  minimum  de  texte  sur  les  diapos 

•  A  vérifier  le  timing  de  votre  présentation  avec  d'aller  voir  vos  interlocuteurs 

•  A  ne  pas  avoir  de  fautes  d'orthographe 

•  A  varier  les  médias  sur  les  diapos  (photos,  illustrations,  vidéos,  animations) 

•  Préparez  toujours  une  version  papier  de  vos  supports  au  cas  où  il  n'y  aurait  pas  de 
prise  ou  un  problème  avec  votre  matériel  informatique. 

9.7  Gérer  les  objections 

La  gestion  des  objections  à  aussi  bien  sa  place  dans  le  présent  chapitre  que  dans  celui 
concernant  la  gestion  des  réunions. 

Je  propose  ici  quelques  éléments  clés  pouvant  être  utile  dans  le  cas  où  des  interlocuteurs 
émettent  des  objections  à  votre  projet,  vos  idées  ou  vos  opinions.  Si  une  objections  est 
nécessite  des  recherches  ultérieures,  envoyez  la  réponse  avec  un  e-mail  à  chaque  personne 
intéressée  en  mettant  bien  en  évidence  la  liste  des  personnes  à  qui  vous  avez  envoyé  le  mail 
(évitez  donc  le  CCi).  Ainsi,  personne  ne  se  demandera  ce  que  vous  avez  dit  aux  autres. 

1.  Ecoutez  l'objection  attentivement  et  sans  interruption  et  encouragez  l'interlocuteur  à 
donner  un  maximum  de  détails.  Si  vous  précipitez  la  discussion  vous  risquez  soit  de 
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tomber  dans  un  piège  volontaire,  soit  de  parler  d'un  autre  problème  auquel  votre 
interlocuteur  n'avait  pas  pensé. 

2.  Posez  des  questions  afin  d'en  savoir  un  maximum  sur  l'objection  ou  le  problème. 
Profitez  des  réponses  données  par  votre  interlocuteur  pour  penser  à  la  prochaine 
question  et  à  l'éventuel  piège  dans  lequel  il  souhaite  vous  amener. 

3.  Reformulez  ensuite  les  propos  de  votre  interlocuteur  si  le  sujet  est  très  sensible 
financièrement  ou  techniquement  parlant. 

4.  Répondez  à  votre  interlocuteur  en  donnant  un  maximum  de  détails  et  demandez-lui  s'il 
confirme  ou  valide  votre  réponse.  Pour  confirmer  vous  pouvez  ajouter:  Cela  répond  à 
la  question  que  vous  avez  soulevée,  n'est-ce  pas? 

5.  Effectuez  une  rupture  entre  la  résolution  du  problème  et  le  prochain  sujet  en  lançant 
un  A  propos...  À  ce  moment-là,  tournez  une  page  de  votre  classeur  ou  de  votre 
diaporama  pour  montrer  quelque  chose  qui  n'a  plus  rien  à  voir  avec  son  objection. 
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10.  Éthique 

Curieusement,  l'éthique  et  l'intégrité  sont  très  rarement  abordées  dans  les  ouvrages  de  gestion 
de  projets.  J'ai  souhaité  par  conviction  personnelle  et  par  idéalisme  faire  un  petit  crochet  sur 
ce  sujet  qui  me  semble  lui  aussi  fondamental  pour  l'évolution  à  long  terme  des  conditions 
humaines  (économiques)  et  de  son  environnement  naturel. 

•  Le  mensonge  dans  quelque  situation  que  ce  soit  est  à  prohiber 

•  Ne  pas  accepter  un  travail  si  l'on  n'a  pas  les  compétences  (ou  demander  si  cela  ne 
dérange  pas  qu'on  n'ait  pas  encore  les  compétences) 

•  Les  collaborateurs  ne  dépasseront  pas  le  nombre  d'heures  prévus  dans  leur  contrat  sauf 
accord  écrit  des  supérieurs  (pour  éviter  les  mauvaises  surprises  quelques  années  plus 
tard...) 

•  Les  urgences  dans  le  cadre  des  projets  ne  doit  pas  survenir  dans  la  vie  privée  des 
ressources  sauf  accord  préalable  non  contraint 

•  Refuser  toute  pratique  et  méthodes  de  travail  douteuses,  frauduleuses  et  non 
respectueuses  des  conditions  humaines  ou  de  la  vie 

•  Il  faut  toujours  travailler  dans  le  respect  des  lois  et  des  normes 

•  La  qualité  et  le  service  utile  doit  être  prioritaire  face  toute  autre  considération 

•  Les  règlements  d'entreprises  ou  de  confidentialité  ne  sont  pas  au-dessus  des  lois  et  de 
l'éthique 

•  Toute  activité  illégale  ou  usurpation  de  compétences  ou  de  diplômes  sera 
communiquée  à  une  autorité/institution  compétente  avec  preuves  écrites 

•  Refuser  de  travailler  avec  des  entreprises  qui  ne  respectent  pas  l'humain  ou 
l'environnement 

•  L'éthique  passe  avant  les  termes  contractuels  de  travail  (même  si  la  loi  dit  le 
contraire!) 

Enfin  indiquons  que  selon  le  PMI  (et  la  législation  de  la  majorité  des  pays)  qu'il  n'y  a  pas  à 
s'inquiéter  si  un  employé  utilise  des  compétences  extrêmement  pointues  et  sensibles  acquises 
dans  un  emploi  précédent  pour  un  projet  en  cours  chez  son  nouvel  employeur.  Les  contrats  de 
confidentialité  interdisent  seulement  de  communiquer  des  méthodes  de  travail  ou  secrets 
industriels  mais  pas  d'utiliser  un  savoir  acquis  (du  moins  jusqu'à  preuve  du  contraire...). 


Ingénierie  de  Gestion  de  projets 


421/547 


11.  Gestion  de  la  connaissance 


Les  étapes  de  gestion  de  la  connaissance  (knowledge  management)  permettent  (comme  le 
BABOK  le  recommande  par  ailleurs...)  de  conserver  la  richesse  des  apprentissages  de 
l'entreprise  (et  donc  implicitement  de  ses  employés),  d'accélérer  certaines  décisions 
stratégiques,  de  réduire  les  pertes  de  temps  et  d'argent  de  recherche  de  l'information,  de 
réduire  la  résistance  au  changement,  d'accélérer  la  courbe  d'apprentissage  sans  avoir  à  payer 
de  formations  et  d'avoir  une  gestion  structurée  du  changement. 

Avec  les  techniques  de  gestion  de  la  connaissance  la  donnée  brute  devient  une  information 
lorsqu'elle  est  placée  dans  le  bon  contexte,  puis  devient  une  connaissance  lorsqu'elle  est  liée 
aux  expériences,  aux  idées  et  aux  jugements  des  personnes. 

La  dernière  étape  correspond  au  moment  où  la  connaissance  partagée  devient  le  sens 
commun,  le  bon  sens  que  l'on  retrouve  dans  les  bonnes  pratiques. 

Ce  domaine  de  la  gestion  de  projets  (plus  généralement  de  la  gestion  d'entreprise)  est  souvent 
négligé.  Ceci  a  pour  conséquence  que  lors  du  départ  d'un  collaborateur  (expert  ou  non)  pour 
quelque  raison  que  ce  soit  (démission,  licenciement,  accident,  retraite,  etc.)  de  nombreux 
acteurs  sont  au  dépourvu  car  ses  activités  et  son  savoir-faire  n'ont  jamais  été  documentés. 

Certes  il  y  a  une  dizaine  d'années  nous  avions  l'excuse  de  ne  pas  avoir  d'outils  appropriés  à  la 
gestion  de  la  connaissance  mais  aujourd'hui  avec  les  outils  informatiques  gratuits  (comme 
Wikimedia)  ou  payants  (comme  SharePoint)  il  n'y  a  plus  vraiment  d'excuse  autre  que  la 
mauvaise  foi. 

Voici  un  diagramme  simple  représentant  la  manière  de  mette  en  place  un  système  de  gestion 
de  la  connaissance  au  sein  d'une  organisation: 


\ 

Établir  la 
stratégie  de  la 
gestion  de  la 
connaissance 

v _ ) 


C  T!  ^ 

Identifier  et 
recueillir  les 
données  en 
leur  attribuant 
un  numéro 
d'identifiant 
(KB...) 

V _ _ _ _ _ J 


/  N 

Stocker  et 
maintenir  les 
données 


v _ / 


(  N 

Analyser  et 
transformer  en 
information 
intelligible  et 
normalisée 

V _ y 


/  "N 


Communiquer 
et  transféer 
l'informaiton 


v _ y 


Ingénierie  de  Gestion  de  projets 


422/547 


Vincent  ISOZ 


12.  Applications  numériques 

Dans  les  cours  que  je  dispense  je  fournissais  toujours  la  théorie  à  part  des  documents 
d'exercices.  J'ai  pu  observer  avec  l'iPad  ou  le  Kindel  qu'il  était  plus  pratique  de  rationaliser  le 
nombre  de  fichiers  afin  d'éviter  le  jonglage  incessant  entre  les  différents  documents.  Donc  j'ai 
compilé  ci-dessous  tous  les  exercices  pour  le  plus  grand  bonheur  des  utilisateurs  de  tablettes 
électroniques. 

En  plus,  en  lisant  différent  ouvrages  de  méthodologie  de  gestion  de  projet  comme  Hermès, 
IPMA,  PMBOK,  ISO,  PRINCE2,  BABOK  j'ai  remarqué  qu'il  n'y  avait  jamais  d'application 
pratiques  calculatoires  (excepté  Six  Sigma  mais  qui  est  forcément  destiné  qu'à  des  ingénieurs 
et  scientifiques).  Donc  finalement  il  vaut  peut-être  mieux  que  je  donne  moi-même  l'exemple 
en  associant  théorie  et  exercice. 

12.1  Exemples  en  gestion 

J'ai  rassemblé  ici  quelques  exemples  que  je  considère  que  le  minimum  minimorum  que  doit 
connaître  un  responsable  de  projet  en  termes  techniques  de  base  en  décisionnel  et  gestion. 
Certains  exemples  ont  simplement  été  repris  de  mon  livre  sur  le  logiciel  Minitab. 

Les  démonstrations  mathématiques  peuvent  toutes  être  trouvées  dans  mon  livre  électronique 
Mathématiques  appliquées. 


12.1.1  Critères  décisionnels  classiques 

Énoncé: 

Une  entreprise  envisage  les  trois  projets  suivants  Pj,  P 2,  P3  avec  leurs  gains  respectifs. 


- 7 - 

Etat  de  la  nature 

Défavorable 

Favorable 

Très  favorable 

Projet  Pj 

l'200 

l'500 

l'800 

Projet  P 2 

700 

900 

l'200 

Projet  P 3 

-500 

l'200 

l'600 

Nous  remarquons  tout  de  suite  qu'il  s'agit  ici  d'un  jeu  unilatéral.  Il  n'y  donc  pas  de 
confrontation  avec  un  autre  décisionnaire  comme  c'est  le  plus  souvent  le  cas  en  théorie  de  la 
décision. 

Il  est  demandé  de  classer  les  projets  en  fonction  des  critères  suivants: 

El.  Critère  du  Maximin  (ou  de  Wald) 

E2.  Critère  du  Maximax 

E3.  Critère  de  Hurwitz  avec  p= 0.7 

E4.  Critère  de  Laplace 

E5.  Critère  de  Savage  (ou  du  Minimax  regret) 
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Solutions: 


51.  Pour  appliquer  le  critère  de  Wald  il  faut  dans  un  premier  temps  déterminer  pour  le 
décisionnaire  le  gain  (utilité)  minimum  de  chacune  des  stratégies: 

Pour  le  projet  Pf.  Min{  l'200,  1,500,1'800}=1’200 

Pour  le  projet  Pï.  Min{700,  900,1'200}=700 

Pour  le  projet  P 3 :  Min{-500,  r200,l'600}=-500 

Selon  ce  critère,  c'est  le  projet  1  qu’il  convient  de  retenir,  en  effet,  parmi  les  résultats  les  plus 
faibles  des  trois  projets,  c'est  celui  qui  correspond  au  plus  élevé. 

52.  Pour  appliquer  le  critère  du  Maximax  il  suffit  de  retenir  le  plus  élevé  de  chaque  projet  en 
fonction  des  différents  états  de  la  nature,  soit: 

Pour  le  projet  Pp.  Min{  l'200,  l'500,l'800}=l'800 

Pour  le  proj  et  P 2 :  Min  {700,  900,  l'200}=l  '200 

Pour  le  projet  P3 :  Min{-500,  l'200,-500}=l'600 

Le  maximum  des  maximums  étant  l'800  c'est  à  nouveau  le  projet  1  qui  est  retenu. 

53.  Pour  appliquer  le  critère  de  Hurwitz  (dans  sa  version  simple)  on  choisit  (on  peut 
démontrer  d'où  vient  cette  valeur  mais  cela  sort  du  cadre  ce  cours)  p= 0.7  et  la  théorie  de  base 
nous  impose  d'utiliser  que  deux  issues.  Nous  prendrons  alors  seulement  les  optimistes  et 
pessimistes: 


État  de  la  nature 

Défavorable 

Très  favorable 

Projet  Pi 

l'200 

1*800 

Projet  P 2 

700 

1*200 

Projet  P 3 

-500 

l'600 

L'espérance  de  gain  est  alors: 

Pour  le  projet  P,:  1*800  •  0.7  + 1*200(1  -  0.7)  =  l'620 

Pour  le  projet  P2 :  1*200  •  0.7  +  700(1  -  0.7)  =  1*050 

Pour  le  projet  P 3:  l'600  •  0.7  -  500(1  -  0.7)  =  970 

Ainsi  avec  ce  critère  c'est  le  projet  1  à  nouveau  qu'il  convient  de  choisir. 

Remarque:  cette  méthode  est  à  prendre  avec  des  pincettes  si  non  appliquée  avec  un  spécialiste 
qui  connaît  les  outils  mathématiques  qui  se  cachent  derrière 

S4.  Pour  appliquer  le  critère  de  Laplace,  il  suffit  d'appliquer  donc  une  à  chaque  stratégie  de 
projet.  Ainsi: 
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Pour  le  projet  Pf.  E(PX  )  =  il'200  +  il'500  +  ^l'800  =  l'500 


Pour  le  projet  P2 :  E(P2  )  =  ^700  +  ^900  +  ^1200  =  933.34 


Pour  le  projet  P?:  E(P3)  =  -^500  +  ^1200  +  ^1600  =  766.67 


Ainsi  avec  ce  critère  c'est  le  projet  1  à  nouveau  qu'il  convient  de  choisir. 

S5.  Pour  appliquer  le  critère  de  Savage  il  faut  d'abord  créer  la  matrice  des  regrets. 

Si  l'état  de  la  nature  est  défavorable,  le  résultat  le  plus  élevé  est  de  l'200,  nous  allons  alors 
tout  report  à  cette  valeur  numérique  et  faires  les  différences  arithmétiques  avec  les  autres 
gains  de  la  même  colonne,  et  de  même  pour  chaque  autre  colonne  avec  l'500  et  l'800. 


Etat  de  la  nature 

Défavorable 

Favorable 

Très  favorable 

Projet  P 1 

0 

0 

0 

Projet  P2 

500 

600 

600 

Projet  P 3 

1700 

300 

200 

Nous  avons  alors: 

Regret  maximum  pour  le  projet  Pj:  0 
Regret  maximum  pour  le  projet  P 2:  600 
Regret  maximum  pour  le  projet  P 3:  1700 

Il  convient  enfin  de  choisir  le  projet  qui  présente  le  regret  le  moins  élevé,  donc  dans  cet 
exemple  simple,  c'est  à  nouveau  le  projet  1. 

Pour  conclure,  il  convient  de  rappeler  qu'une  décision  d'investissement  est  une  opération 
complexe  qui  fait  intervenir  plusieurs  variables  tant  quantitatives  que  qualitatives  et  qu'elle  ne 
peut  s'appuyer  que  sur  un  seul  critère  ou  même  sur  cinq! 
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12.1.2  Arbre  de  décision 

s 

Enoncé: 


Imaginons  une  société  informatique  B  en  concurrence  potentielle,  pour  un  projet  de  migration 
informatique  international  avec  une  autre  société  A  (cette  dernière  pouvant  être  vue  comme  un 
ensemble  de  concurrents  aussi!). 

En  simplifiant  quelque  peu,  mais  sans  être  toutefois  hors  de  la  réalité,  considérons  que  deux 
choix  sont  ouverts  à  B:  viser  "cher"  ou  viser  "bas". 


Supposons  que  nous  savons  également  que  dans  le  passé  B  a  soumis  une  proposition  pour 
chaque  appel  d'offres  de  ce  type,  alors  que  le  groupe  A  ne  l'a  fait  que  dans  60%  des  cas  (pas 
de  fonction  de  distribution  de  probabilité  dans  notre  scénario!). 

Nous  savons  également  que: 

-  Si  B  soumet  cher  et  est  le  seul  à  soumettre  une  proposition,  le  bénéfice  attendu  est  de 
22  millions. 

-  Si  B  soumet  un  prix  élevé  mais  se  trouve  en  concurrence  avec  le  groupe  A,  il  obtiendra 
le  contrat  selon  le  niveau  de  prix  demandé  par  le  groupe  A.  Dans  ce  cas,  il  sait  qu'il 
obtiendra  en  moyenne  1  million. 

-  Si  enfin  B  soumet  à  un  prix  bas,  il  est  sûr  d'obtenir  le  contrat  et  de  réaliser  un  bénéfice 
de  10  millions. 

Donc  dans  le  cadre  où  le  choix  du  projet  est  déterminé  uniquement  par  son  prix  (au  détriment 
de  la  qualité  comme  dans  la  réalité...)  la  question  qui  se  pose  est  alors  la  suivante:  Que  doit 
faire  B,  si  aucune  information  complémentaire  ne  peut  être  obtenue? 

Remarque :  Ceci  constitue  une  situation  du  type  "décision  sans  information" 

Solution: 

Pour  répondre  à  cette  question,  nous  représentons  tout  d'abord  le  problème  à  résoudre  sous 
une  forme  graphique  fort  logique  (qui  est  pour  l'instant  assez  simple  à  mettre  aussi  sous  forme 
de  tableau)  avec  le  logiciel  TreeAge: 


<  1 


<]  22 


Ensuite  en  lançant  le  calcul  de  l'espérance  à  chaque  branchement,  TreeAge  nous  donne 
simplement: 
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Concurrence 


Cher 


__ 


Appel  Offre 


O* 


-CX  9.40 


IT 


o.eo 
oncurrence 


CK  Pas  cher  :  10.00 


0.40 


\  Pas  cher 


<  10.00;  P  =  1.00 


1.00 


22.00 


Ainsi,  la  réponse  à  la  première  question  est  que  la  stratégie  donnant  l'espérance  de  gain  la  plus 
grande  est  la  stratégie  "Pas  Cher"  car  il  y  a  un  gain  espéré  de  10  millions. 

Avec  la  première  décision  (Cher)  nous  gagnerions  en  moyenne  que: 

22  0.4  +  1  0.6  =  9.4 
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12.1.3  Gantt 

s 

Enoncé: 

Chargé  de  l'organisation  d'un  projet  d'enquête  marketing,  vous  devez  établir  la  planification 
des  tâches  en  fonction  des  contraintes  suivantes: 


TACHES 

DESCRIPTION 

TACHES 

ANTERIEURES 

DUREE 

(SEMAINES) 

A 

Contacter  un 
statisticien 

/ 

1 

B 

Constituer  un 
échantillon 

/ 

3 

C 

Rechercher  des 
instituts  de 
sondage 

/ 

1 

D 

Elaborer  le 
questionnaire 

/ 

4 

E 

Sélectionner 
l'institut  de 
sondage 

C 

1 

F 

Test  du 
questionnaire 

D 

1 

G 

Administration  de 
l'enquête 

B,  I 

5 

H 

Mise  à  disposition 
des  enquêteurs 

E 

1 

I 

Essai  du 
questionnaire 

H,  F 

2 

J 

Saisie  des 
données 

G 

1 

K 

Relance  des  non 
répondants 

J 

2 

L 

Administration 
des  relances 

K 

1 

M 

Traitement  des 
données 

A,  J,  N 

2 

N 

Saisie  des 
relances 

L 

1 

O 

Résultat  de 
l'enquête 

M 

1 

Etablissez  un  diagramme  de  Gantt  dans  MS  Project  pour  chacun  des  cas  suivants: 

El.  Sachant  que  l'enquête  peut  commencer  la  semaine  n°5  au  début,  quand  sera-t-elle 
terminée  avec  un  jalonnement  au  plus  tôt  et  des  liaisons  entre  les  tâches  de  type  fin  à  début. 
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E2.  Sachant  que  l'enquête  doit  se  terminer  la  semaine  n°26  en  fin,  quand  doit-elle  commencer 
avec  un  jalonnement  au  plus  tard  et  des  liaisons  entre  les  tâches  de  type  fin  à  début. 

Solutions: 

SI.  Avec  un  jalonnement  au  plus  tôt,  il  faut  insérer  les  tâches  sans  liens  d'antériorité  à  partir 
de  la  semaine  5.  Ensuite,  on  continue  en  inscrivant  les  tâches  qui  ont  leurs  tâches  antérieures 
réalisées  et  ainsi  de  suite,  de  gauche  à  droite.  Cela  nous  permet  d'obtenir  le  diagramme 
suivant: 


Au  plus  tôt 

Semaines  na 

Tâches 

Tâches 

Durée 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

avant  : 

a 

i 

- 

b 

3 

- 

c 

1 

- 

d 

4 

- 

e 

1 

C 

f 

1 

D 

g 

5 

B 

i 

h 

i 

E 

i 

2 

H 

F 

j 

1 

G 

k 

2 

J 

1 

1 

K 

m 

2 

A 

J 

A/ 

n 

1 

i 

0 

i 

M 

L'enquête  sera  donc  terminée  à  la  fin  de  la  semaine  n°24 

S2.  Avec  un  jalonnement  au  plus  tard,  il  faut  insérer  les  tâches  sans  liens  de  postériorité  à 
partir  de  la  semaine  26.  Ensuite,  on  continue  en  inscrivant  les  tâches  qui  ont  leurs  tâches 
postérieures  réalisées  et  ainsi  de  suite,  de  droite  à  gauche.  Cela  nous  permet  d'obtenir  le 
diagramme  suivant: 
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Au  plus  tard 

Semaines  n° 

Tâches 

Tâches 

Durée 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

après  : 

a 

1 

m 

b 

3 

9 

c 

1 

e 

d 

4 

f 

e 

1 

h 

f 

1 

i 

g 

5 

j 

h 

1 

i 

i 

2 

9 

j 

1 

k 

m 

k 

2 

i 

1 

1 

n 

m 

2 

0 

n 

1 

m 

0 

1 

- 

_ 

_J _ 1 _ 1 _ 1 _ 1 _ 1 _ 1 _ 1 _ 1 _ 1 _ 1 _ 1 _ 1 _ 1 _ 1 _ 1 _ 1 _ 1 _ 

L'enquête  doit  donc  commencer  au  début  de  la  semaine  n°7 
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s 

Enoncé: 

Un  projet  se  compose  des  tâches  suivantes: 


TACHES 

DURÉE 

TACHES 

ANTERIEURES 

A 

3 

E 

B 

4 

K,  C 

C 

3 

- 

D 

2 

E,  J 

E 

2 

- 

F 

3 

G,  L 

G 

4 

- 

H 

2 

A,  M,  R 

J 

2 

E 

K 

2 

C 

L 

5 

G 

M 

4 

C 

N 

3 

G 

R 

2 

J 

Représenter  les  tâches,  tâches  critiques,  le  chemin  critique,  les  marges  libres  et  totales  des 
tâches  dans  MS  Office  Project 

Solution: 


Task  Name 

Duration 

Free  Slack 

Total  Slack 

Début 

0  days 

0  days 

0  days 

A 

3  days 

2  days 

6  days 

B 

4  days 

0  days 

0  days 

C 

3  days 

0  days 

4  days 

D 

2  days 

7  days 

7  days 

E 

2  days 

0  days 

5  days 

F 

3  days 

1  day 

1  day 

G 

4  days 

0  days 

0  days 

H 

2  days 

4  days 

4  days 

J 

2  days 

0  days 

5  days 

K 

2  days 

8  days 

8  days 

L 

5  days 

0  days 

0  days 

M 

4  days 

0  days 

4  days 

N 

3  days 

6  days 

6  days 

R 

2  days 

1  day 

5  days 

Fin 

0  days 

0  days 

0  days 
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12.1.5  PERT  Probabiliste  (PNET)  Bêta 

s 

Enoncé: 

Soit  di  la  durée  des  tâches  d'un  chemin  critique  composé  des  tâches  B,D,F,G  d'un  projet 

donné  et  le  choix  suivant  pour  les  durées  optimistes  pessimiste  et  attendues  de  chaque  tâche 
respectivement: 

to(Ti)  =  0.1-di  lr{T,)  =  l.2d,  tv(T,)  =  d, 

Nous  imaginons  que  les  tâches  critiques  sont  telles  que  leurs  durées  attendues  sont: 

Tg  =1*Td  =  12,Tf  =6,Tg  =2 


En  déduire: 

1.  La  durée  probable  (espérance)  fPr ,  l'écart-type  g  et  la  valeur  modale  selon  le  PMBOK52 

2.  La  durée  de  chacune  des  tâches  avec  un  niveau  de  confiance  de  95% 

3.  La  probabilité  cumulée  que  chaque  tâche  se  termine  dans  le  temps  attendu. 

4.  La  durée  totale  du  chemin  critique  et  son  écart-type  (toujours  selon  le  PMBOK) 

5.  La  probabilité  cumulée  que  le  projet  soit  terminé  avant  27  jours. 

6.  Calculez  la  durée  totale  du  projet  avec  1  chance  sur  20  seulement  de  la  dépasser. 
Solutions: 

1.  Sachant  que  selon  le  PMI: 


E{X)  = 


tn  +  4  Ur  +  tu 


—  U 


Pr 


et: 


ct(T)  =  . 


I  (tp  Jr)  ) 


=  JV(T) 


et: 


M0  = 


2f  p  +  2t0  +  a/2  (t  p  —  t  q  ) 


Nous  obtenons  après  application: 


52  Référentiel  de  Gestion  de  projets:  Project  Management  Body  of  Knowledge 
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tPr(rB)  =  6.88  fft(7i,)  =  11.8  tPl  (Tf  )  =  5.9  fft(rG)  =  1.96 
<t(Tb)  =  0.583  cr(TD)  =  1  cr(TF)  =  0.5  <t(Tg)  =  0.166 


M0  =7.88 


M0  =13.52 


M0  =  6.76 


M0  =  2.25 


2.  La  durée  de  chacune  des  tâches  avec  un  niveau  de  confiance  de  95%  ne  peut  être  obtenue 
formellement.  Il  faut  passer  par  exemple  par  MS  Excel  ou  @Risk  de  Palissade. 

Nous  avons: 


tP[  (Tb  \5%  =BETA.INVERSE(0.95;3+RACINE(2);3-RACINE(2);0.7*7;1.2*7)=8.25 
tPr  (Td  )95%  =  BETA.INVERSE  (0.95;3+  RACINE(2);3-  RACINE(2);0.7*12;1.2*12)=14.14 
/pr  (Tf  )95%  =  BETA.INVERSE  (0.95 ;3+  RACINE(2);3-  RACINE(2);0.7*6;1.2*6)=7.07 
tpr  (Tg  )95%  =  BETA.INVERSE  (0.95 ;3+  RACINE(2);3-  RACINE(2);0.7*2;1.2*2)=2.35 

avec  un  logiciel  plus  performant  que  MS  Excel  nous  avons  pour  la  fonction  de  distribution  de 
la  tâche  B  où  nous  voyons  bien  sur  l'image  les  valeurs  calculées  précédemment: 


Par  contre  nous  voyons  que  la  moyenne  donnée  par  le  logiciel  @Risk  ne  correspond  pas  à  la 
valeur  obtenue  à  l'aide  de  formule  donnée  par  le  PMBOK  (PMI)  qui  est  de  6.88  et  donc  sous 
évalue  de  manière  non  négligeable  la  vraie  espérance  mathématique. 

Au  fait  la  raison  est  simple  car  le  PMBOK  (PMI)  fait  une  erreur  en  confondant  la  valeur 
modale  et  la  valeur  attendue.  Nous  n'avons  en  l'occurrence  démontrés  dans  le  chapitre  de 
Statistique  que  nous  n'avons  pas: 


Ingénierie  de  Gestion  de  projets 


433/547 


mais: 


-  tPr 


et  vous  pouvez  vérifier. ...!!!  On  comprend  alors  mieux  aussi  pourquoi  nombre  de  projets 
échouent... 

3.  La  probabilité  cumulée  que  chacune  des  tâches  se  termine  dans  le  temps  attendu  ne  peut 
être  obtenue  formellement.  Il  faut  passer  par  exemple  par  MS  Excel  ou  @Risk  de  Palissade. 
Nous  avons  alors: 

P(Tb  <  7)  =LOI.BETA(7 ;3+  RACINE  (2);3-RACINE(2);0.7*7;1.2*7)=20.79% 
P(Td  <  12)  =  LOI.BETA  (12;3+  RACINE  (2);3-  RACINE  (2);0.7*12;1.2*12)=20.79% 
P(Tf  <  6)  =  LOI.BETA  (6;3+  RACINE  (2);3-  RACINE(2);0.7*6;1.2*6)=20.79% 
P(Tf  <  2)  =  LOI.BETA  (2;3+  RACINE  (2);3-  RACINE(2);0.7*2;1.2*2)=20.79% 

Nous  voyons  donc  que  la  probabilité  cumulée  de  tomber  juste  dans  la  durée  estimée  par  le 
responsable  de  projet  est  assez  faible. . .  !  Alors  que  la  probabilité  de  tomber  sur  la  valeur 
Modale  est  bien  plus  grande!  !  ! 

4.  La  durée  estimée  du  chemin  critique  est  donnée  par: 


‘C=£Ur)=2«- 54 


La  variance  du  chemin  critique  est  alors  (si  les  variables  aléatoires  sont  indépendantes 
rappelons  que  la  variance  d'un  somme  est  égale  à  la  somme  des  variances  quelque  soit  la  loi!): 


yes,  =  £  V{ri)  =  1.618  =><7  =  >/L618  =1.27 


5.  Calculons  la  probabilité  pour  que  la  durée  du  chemin  critique  soit  inférieure  à  la  valeur  27. 
La  loi  de  Gauss  centrée  réduite  nous  permet  d'écrire: 


k- jU  _k-tPl  _  27 - 26.54 


a  a  1.27 


En  utilisant  MS  Excel  nous  avons  maintenant: 

=LOI.NORMALE.STANDARD(0. 35 3 )=63 .82% 

Donc  nous  avons  une  probabilité  cumulée  de  -64%  d'avoir  une  durée  inférieure  ou  égale  à  27 
jours! 
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Nous  aurions  obtenu  le  même  résultat  avec: 

=LOI.NORMALE(27  ;26.54;  1 .27;  1)=63.82% 

6.  Nous  utilisons  pour  déterminer  la  durée  avec  une  couverture  du  risque  de  95%: 


=LOI.NORMALE.INVERSE(95%;26.54;1.27)=28.62 


Ingénierie  de  Gestion  de  projets 


435/547 


Vincent  ISOZ 


12.1.6  Coût  non  qualité  selon  modèle  Taguchi 

s 

Enoncé: 

Dans  un  projet,  une  tâche  de  4  jours  à  une  marge  totale  de  2  jours.  Si  nous  sortons  de  cette 
marge,  le  projet  va  prendre  du  retard  pour  un  coût  de  1200.-/jour. 

Quel  est  le  coût  réel  associé  à  1,  2  et  3  jours  de  retard  selon  le  modèle  de  Taguchi? 

Solution 

Nous  avons: 

L(y)  =  k(y-T)2  =>  L(  1)  =  (5 - 4)2  =  600. - /  j. 

L(y)  =  k(y-T)  =>  L( 2)  =  ( 6 - 4)2  s  2 1 400. - /  j. 

L(y)  =  k(y-T)2  =>  L( 3)  =  (7  - 4)2  =  5 '400. - /  j. 
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12.1.7  tV@r  et  fY @r 

Enoncés: 

El.  Calculez  la  durée  d'un  projet  de  26.5  jours  planifié  ayant  un  écart-type  1.27  jours  pour 
couvrir  99%  des  dépassements. 

E2.  Calculez  le  budget  prévisionnel  d'un  projet  ayant  un  coût  planifié  de  ~78'000.-  et  écart- 
type  de  3'900.-  pour  couvrir  95%  des  dépassements. 

Solutions: 

51.  Nous  savons  que  sous  certaines  hypothèses: 

tV@R  =  PNW)(X>95%)-aDurée 

La  réponse  sera  donnée  en  utilisant  la  relation  suivante  dans  MS  Excel: 

=  1  Oî.NORM  Al  E.STAND ARD.ÎNVERSE  (95%)*  1.27=2.1 
Ce  qui  donne  une  durée  totale  sécurisée  de: 

decst95%  =  26.5  +  2.1  =  28.6 

52.  Nous  savons  que  sous  certaines  hypothèses: 

/V@R  =  PN(0  \}  (V  >  95%)  •  crCoût 

La  réponse  sera  donnée  en  utilisant  la  relation  suivante  dans  MS  Excel: 

=  LOI.NORMALE.STAND ARD.INVERSE  (95%)*3'900.-  =6'400.- 
Ce  qui  donne  un  budget  prévisionnel  sécurisé  de: 

Becst95%  =  78  ’  000  +  6'400  =  84' 400 
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12.1.8  Rendement  global  combiné  de  processus 

s 

Enoncé: 

Soit  le  processus  de  projet  répétitif  suivant: 


dont  le  niveau  de  qualité  de  certaines  étapes  a  été  indiqué  en  rouge.  Veuillez  calculer  le  RTY 
(Taux  de  Rendement  Global  Combiné  ou  Rolled  Troughput  Yield)  de  l'ensemble  du  processus 
et  déterminez  son  niveau  de  qualité  Sigma  basé  sur  la  méthodologie  Six  Sigma  (ISO  13053- 
1:2011). 


Solution: 

En  ouvrant  MS  Excel  et  en  y  reportant  les  différents  taux  nous  avons  alors  en  les  multipliant: 


A 

1 

RTY 

2 

98% 

3 

85% 

4 

96% 

5 

99% 

6 

76% 

7 

99% 

3 

95% 

9 

=PRODUCTfA2:A8)=57% 

soit  un  taux  de  rendement  global  combiné  de  -57%. 


En  prenant  le  tableau  de  niveau  de  qualité  Six  Sigma  (voir  mon  livre  de  Mathématiques 
Appliquées): 


Étapes/Qualité% 

±3  a 

±4  CT 

±5  CT 

±6  cr 

1 

93.32 

99.38 

99.98 

99.9996 

7 

61.63 

95.73 

99.84 

99.9976 

10 

50.08 

93.96 

99.77 

99.9966 
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20 

25.08 

88.29 

99.54 

99.9932 

40 

6.29 

77.94 

99.07 

99.9864 

60 

1.58 

68.81 

98.61 

99.9796 

80 

0.40 

60.75 

98.16 

99.9728 

100 

0.10 

53.64 

97.70 

99.996 

cela  correspond  donc  à  la  ligne  numéro  2  et  alors  à  un  niveau  de  qualité  d'environ  3  sigma. 
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12.1.9  Rendement  global  combiné  de  procédé  de 
fabrication 

Énoncé: 

Soit  un  procédé  de  production  industrielle  dont  le  taux  de  non-rebus  dans  le  cas  du 
prototypage  d'un  projet  a  été  indiqué  à  chacune  des  étapes  ci-dessous: 


Processus 


Rendement 


90%  90%  90%  90% 


RT  Y 
65.6% 


Quelle  quantité  Q  bien  définie  de  produits  (supposés  utiliser  qu'un  seul  composant  de  chaque 
étape)  au  début  de  la  chaîne  faudra-t-il  prévoir  à  l'étape  A  et  à  l'étape  B  pour  avoir  un  RTY  de 
100%  à  la  fin? 

Solution: 

Le  nombre  de  composants  à  prévoir  à  l'étape  A  sera  de: 

A-  — =  — — —  =  152.42% 

RTY  65.6% 

par  rapport  aux  prévisions  initiales.  Soit  52.42%  de  composants  A  de  plus  que  prévus. 

Il  faudra  prévoir  à  l'étape  B: 

B  = - £ - =  — =  137. 17% 

90% -90% -90%  72.9% 

soit  37.17%  de  composants  de  plus.  Et  ainsi  de  suite... 

Remarque:  En  toute  rigueur  le  taux  de  rebus  (et  respectivement  de  non-rebus)  est  une  variable 
aléatoire.  Donc  pour  savoir  combien  on  devrait  lancer  de  pièces  à  chaque  étape  on  utilisera 
typiquement  dans  les  grosses  productions  la  fonction  CRITERE.LOI.BINOMIALE  de 
MS  Excel  ce  qui  donnera  par  dans  le  cas  présent,  19  chances  sur  20  d'arriver  à  100  pièces  de 
RTY  si  en  A  nous  en  prévoyons  -169.  Donc  une  différence  de  17%  avec  le  calcul  précédent! 
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12.1.10  Analyse  de  Pareto 

s 

Enoncé: 

Responsable  de  l'amélioration  continue  des  ressources  de  vos  projets,  vous  avez  extrait  de  la 
base  de  données  des  ressources  humaines  la  liste  de  tous  les  cours  suivis  en  ne  prenant  que  le 
nom  du  domaine  concerné  et  le  numéro  d'identifiant  de  cours  correspondant  (car  MS  Excel  ne 
sait  pas  faire  d'analyse  de  Pareto  automatique  sur  une  base  autre  que  des  chiffres).  Ce  qui 
correspond  à  2528  lignes  de  données  avec  43  types  de  formations  (ID)  dans  une  feuille 
nommée  Données : 


A 

B 

1 

Titre 

ID 

2 

MS  SQL  Server 

1 

3 

MS  SQL  Server 

1 

4 

MS  SQL  Server 

1 

5 

MS  SQL  Server 

1 

6 

MS  SQL  Server 

1 

7 

MS  SQL  Server 

1 

8 

MS  SQL  Seiver 

1 

9 

MS  SQL  Server 

1 

10 

MS  SQL  Server 

1 

11 

MS  SQL  Server 

1 

12 

MS  SQL  Server 

1 

13 

MS  SQL  Server 

1 

14 

MS  SQL  Server 

1 

15 

MS  Windows  Seiver 

2 

16 

MS  Windows  Server 

2 

17 

MS  Windows  Server 

2 

18 

MS  Windows  Server 

2 

19 

MS  Windows  Server 

2 

20 

MS  Windows  Server 

2 

21 

MS  Windows  Server 

2 

22 

MS  Windows  Server 

2 

23 

MS  Windows  Seiver 

2 

24 

MS  Windows  Server 

2 

Pareto.xls 

Nous  souhaiterions  savoir  quels  sont  les  cours  qui  à  eux  seuls  représentent  80%  des  ventes 
afin  de  pouvoir  se  focaliser  sur  leur  qualité  et  de  développer  la  partie  minoritaire. 

Donnez  cette  analyse  avec  MS  Excel  et  avec  MiniTab. 

Solution: 

D'abord  créez  sur  une  nouvelle  feuille  nommée  Rangée  une  liste  simple  des  numéros  allant  de 
1  à  43  (le  nombre  de  type  de  formations): 
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26  26 


Ensuite,  revenez  dans  la  feuille  Données,  après  avoir  éventuellement  activé  l'Utilitaire 
d' Analyse  de  MS  Excel,  vous  allez  dans  le  menu  Données/Utilitaire  d' Analyse: 


et  prenez  l'option  Histogramme: 
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Histogram 


X] 


Input 

OK 

Input  Range  :  |  Données  !  $ B$ 2  : 

Bin  Range  :  ) Rangée ! $ A$ 1  :  $A$  1  Hl| 

Cancel 

Help  | 

l~~  Labels 

-Output  options 


F  Output  Range: 

i — 

(*  New  Worksheet  Ply: 

||Pareto 

r  New  Workbook 

F  Pareto  (sorted  histogram) 
F  Cumulative  Percentage 
F  Çhart  Output 


vous  y  mettez  les  valeurs  ci-dessus  et  validez  par  OK  pour  obtenir  (nous  avons  un  peu 
amélioré  esthétiquement  le  diagramme  et  avons  mis  en  rouge  la  ligne  limite  représentant  les 
80  %): 


Attention  il  arrive  à  MS  Excel  de  retourner  dans  la  colonne  B  in  des  valeurs  décimales. . .  il 
faut  alors  formater  les  cellules  afin  d'avoir  des  valeurs  entières. 


Nous  voyons  alors  dans  la  colonne  D  que  les  numéros  (5;27;4;6;3;7;21;8;19;14)  du  type  de 
formation  représentant  les  80%  des  prestations  à  eux  seuls. 


Copions  maintenant  les  données  dans  Minitab  qui  lui  est  capable  de  se  baser  sur  des  textes 
pour  faire  un  diagramme  de  Pareto: 
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Ensuite,  allez  dans  le  menu  Stat/Outils  de  qualité/Diagramme  de  Pareto: 


5tat  Graphique  Editeur  Outils  Fenêtre  Aide 
Statistiques  élémentaires  ► 

Régression  ► 

ANÜVA  ► 

DOE  (plan  d'expériences)  ► 

Cartes  de  contrôle  ► 


Outils  de  la  qualité 


Fiabilité/Survie  ► 

Multivarié  ► 

Série  chronologique  ► 

Xableaux  ► 

Tests  non  paramétriques  ► 

Analyse  exploratoire  des  données  ► 

Puissance  et  effectif  de  l'échantillon  ► 


3\ X|q  jnTTnOX 


Carte  d'essais... 

|lV~  Diagramme  de  Pareto. . . 
Causes  et  effets... 


'■■ÿ--  Identification  de  loi  individuelle. 
^  Transformation  de  Johnson. . . 
Analyse  de  capabilité 
Capability  Sixpack 


Etude  de  l'instrumentation 


""x  Analyse  d'accord  d'attribut. 


Carte  multivariée... 

|/^  Diagramme  de  symétrie. . . 


Ll 


[S]  Echantillonnage  d'acceptation  par  attributs. . . 

Echantillonnage  d'acceptation  par  variables  ► 


Nous  obtenons  alors: 
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c 

aj 

E 

ûj 

-Q 

E 

o 

c 

'ÛJ 

Q 


Diagramme  de  Pareto 


Dénombrement 

514 

304 

229 

223 

1S3 

134 

113 

101 

75 

72 

64 

62 

454 

Pourcentage 

20 

12 

9 

9 

7 

5 

4 

4 

3 

3 

3 

2 

10 

%  cum 

20 

32 

41 

50 

57 

63 

67 

71 

74 

77 

00 

02 

100 

100 


80 


60 


40 


20 


(U 

O) 

(D 

4— 1 

C 

oj 

U 

i_ 

D 

O 

a 
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12.1.11  Indice  de  Gini 


Énoncé: 


En  utilisant  le  tableau  généré  par  MS  Excel  dans  l'exercice  précédent: 


A 

B 

C 

D 

E 

F 

GH  1  J  K  L  M  N 

1 

Bin 

Frequencv 

Cumulative  % 

Bin 

Frequencv 

Cumulative  % 

Histogram 

2 

1 

13 

0.51% 

5 

514 

20.33% 

3 

2 

28 

1 .62% 

27 

304 

32.36% 

4 

3 

183 

8.86% 

4 

229 

41 .42% 

5 

4 

229 

17.92% 

6 

223 

50.24% 

cnn  mn  nno/ 

6 

5 

514 

38.25% 

3 

183 

57.48% 

500  - 

■  100.00% 

7 

6 

223 

47.07% 

7 

134 

62.78% 

8 

7 

134 

52.37% 

21 

113 

67.25% 

9 

8 

101 

56.37% 

8 

101 

71 .24% 

10 

9 

7 

56.65% 

19 

75 

74.21% 

/ 

11 

10 

6 

56.88% 

14 

72 

77.06% 

f 

« 

400  - 

/ 

-  80.00% 

13 

12 

4 

59.30% 

26 

62 

82.04% 

/ 

14 

13 

1 

59.34% 

11 

57 

84.30% 

f 

à 

15 

14 

72 

62.18% 

16 

50 

86.27% 

c 

0)  -nn 

f 

-  60.00% 

-  40.00% 

16 

15 

16 

62.82% 

33 

45 

88.05% 

§■  3“  - 

ul 

900  J 

17 

16 

50 

64.79% 

18 

35 

89.44% 

18 

17 

64 

67.33% 

24 

32 

90.70% 

19 

18 

35 

68.71  % 

2 

28 

91 .81  % 

20 

19 

75 

71.68% 

30 

27 

92.88% 

1 

21 

20 

9 

72.03% 

32 

25 

93.87% 

1 

-  20.00% 

22 

21 

113 

76.50% 

25 

23 

94.78% 

23 

22 

19 

77.25% 

22 

19 

95.53% 

24 

23 

5 

77.45% 

15 

16 

96.16% 

25 

24 

32 

78.72% 

40 

16 

96.80% 

26 

25 

23 

79.63% 

1 

13 

97.31% 

n  nno/ 

27 

26 

62 

82.08% 

20 

9 

97.67% 

0  1  !  1 1 1 1 1 1 1 III  lllllllllllllllllll  lllllf  llllllf  llllll  llllllllltllllllllll  IIIIIIIH 

in  en  m  rsj  co  t —  oo  ro  hv_  *=t  —  go  lti  r\i  en  co  m 

h  U.UUyo 

28 

27 

304 

94.11% 

9 

7 

97.94% 

ntN^-^OllDlDlDNNCOromOr- 

Bin 

29 

28 

1 

94.15% 

29 

7 

98.22% 

30 

29 

7 

94.42% 

10 

6 

98.46% 

31 

30 

27 

95.49% 

1  37 

6 

98.69% 

Il  i Frequencv  —«—Cumulative  %  1 

32 

31 

2 

95.57% 

23 

5 

98.89% 

déterminez  l'indice  d'asymétrie  de  Gini  (voir  mon  livre  électronique  sur  les  mathématiques 
appliquées). 


Solution: 


Nous  avons  vu  que  l'indice  de  Gini  était  défini  par  (les  y  correspondent  à  la  colonne  F): 

G= _i+ -SCtt+i +^) 

n  ,=1 


Ce  qui  nous  donne  dans  notre  exemple: 

G  =  -l  +  —  66.77  =  0.55 
43 

Il  y  a  donc  une  assez  forte  inégalité  entre  les  éléments  étudiés  car  si  l'indice  de  Gini  vaut  0 
l'égalité  est  parfait  et  dans  le  cas  extrême  l'indice  vaut  1. 
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12.1.12  Prévision  des  ventes 

s 

Enoncé: 

Une  entreprise  a  représenté  graphiquement  ses  ventes  mensuelles  sous  formes  graphique 
comme  ci-dessous: 


Avec  une  analyse  fréquentielle  des  déviations: 


Elle  fait  alors  l'hypothèse  de  normalité  et  calcule  alors  la  moyenne  est  l'écart-type  suivant: 

ju  =  14  et  o-  =  39 

Afin  de  savoir  si  elle  doit  se  lancer  dans  le  projet  de  restructuration  de  la  ligne  de  produit, ,  la 
direction  souhaiterait  savoir: 

El.  Quelle  est  la  quantité  de  vente  possible  à  1  sigma  pour  le  25eme  mois  et  la  probabilité  de 
dépasser  cette  quantité? 

E2.  Déterminez  la  relation  MS  Excel  à  écrire  pour  connaître  la  probabilité  cumulée  d'en 
vendre  au  moins  un  nombre  XX! 
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Solution: 


S 1 .  La  quantité  des  ventes  pour  le  mois  de  24eme  mois  étant  de  20  pièces,  pour  la  prochaine 
période  (25eme  mois),  sous  l'hypothèse  de  normalité. . .  nous  avons  la  quantité  qui  suit  la  loi 
suivante: 


=20+N(14,39) 

Nous  avons  donc  68%  (1  sigma)  de  probabilité  cumulée  d’avoir  le  mois  prochain  entre: 

[20+14-39, 20+14+39]=[-, 73]  pièces 

Ce  qui  signifie  aussi  que  nous  avons  32%/2=16%  (1  chance  sur  6)  de  probabilité  cumulée  de 
dépasser  les  73  pièces. 

L’intervalle  supérieur  peut  être  calculé  avec  MS  Excel  en  écrivant: 

=LOI.NORMALE.INVERSE(50%+68%/2;14;39)+20 

S2.  La  probabilité  cumulée  d’en  vendre  au  moins  une  quantité  XX  est  donnée  dans  MS  Excel 
par: 


= 1  -LOI.NORM  ALE(XX-20  ;  1 4  ;  39  ;  1  ) 
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12.1.13  Recherche  opérationnelle  dans  l’optimisation  de  la 
production 

Énoncé: 

Supposons  qu'une  usine  fabrique  2  pièces  PI  et  P2  usinées  dans  deux  ateliers  Al  et  A2  dans  le 
cadre  d'un  projet  de  déploiement  d'un  nouveau  produit  sur  le  marché. 

Les  temps  d'usinage  sont  pour  PI  de  3  heures  dans  l'atelier  Al  et  de  6  heures  dans  l'atelier  A2 
et  pour  P2  de  4  heures  dans  l'atelier  Ai  et  de  3  heures  dans  l'atelier  A2. 

Le  temps  de  disponibilité  hebdomadaire  de  l'atelier  Al  est  de  160  heures  et  celui  de  l'atelier 
A2  de  180  heures. 

La  marge  bénéficiaire  est  de  l'200.-  pour  une  pièce  PI  et  l'OOO.-  pour  une  pièce  P2. 

La  question  est:  Quelle  production  de  chaque  type  doit-on  fabriquer  pour  maximiser  la  marge 
hebdomadaire? 

A  résoudre  en  utilisant  la  représentation  graphique  et  MS  Office  Excel! 

Solution: 

D'abord,  il  est  possible  de  poser  le  système  d'inéquations: 

Al:  3-  Xl  +  4-  X2  <  160 
A2 :  6-Xl  +  3-X2<180 
Xl,X2>0 


Ensuite,  la  fonction  économique: 

Z  =  1200  ■  X1  + 1000  •  X  2 

Le  tracé  des  deux  droites  dans  MS  Excel,  donne  le  polygone  des  contraintes  (c'est  que  l'on  fait 
dans  les  petites  classes  d'écoles): 


Ingénierie  de  Gestion  de  projets 


449/547 


Vincent  ISOZ 


où  nous  voyons  de  suite  ou  sont  les  maximums  ainsi  que  l'optimum. 

Pour  résoudre  le  problème  dans  MS  Excel  (eh  oui!  MS  Project  n'est  pas  fait  pour 
l'optimisation. . .  ce  qui  est  logique!),  créez  un  tableau  du  type  suivant: 


A 

B 

C 

47 

48 

Al:  3*X1+4*X2<=160 

XI  : 

49 

A2:  6*X1+3*X2<=180 

X2  : 

50 

X1,X2>=0 

Al  : 

=3*C48+4*C49 

51 

A2  : 

=6*C48+3*C49 

52 

Contrainte  Al  : 

160 

53 

Contrainte  A2  : 

180 

54 

Z=1200*X1+1000*X2 

Fonction  économique  : 

=1200*C48+1000*C49 

et  ensuite,  avec  le  solveur  MS  Excel,  créez  les  contraintes  adaptées  du  type  (attention  les 
références  de  cellules  ne  sont  pas  données  correctement  ci-dessous  afin  de  ne  pas  vous 
mâcher  tout  le  boulot!): 
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Solver  Parameters 


5et  Target  Cell:  [1H1 

EqualTo:  f*-  Max  ^  Min  C  Value  of: 

pBy  Changing  Cells: 

ï  $C$174:$C$175 


F 


5ubject  to  the  Constraints: 


31 


$C$174  >=  0 
$C$175  >=  0 
$C$176  <=  160 
$C$177  <=  130 


n 


JH 


Guess 


Add 


J£l 


Change 

Delete 


5olve  "| 


Close 


Options 


Reset  Ail 


Help 


Les  solutions  seront  alors  après  l’exécution  du  solveur: 

ZI  =  16  pcs.  X  2  =  28  pcs. 
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12.1.14  Recherche  opérationnelle  dans  l’optimisation  de 
bénéfice 

Énoncé: 

Un  fabricant  de  montres  pense  faire  un  bénéfice  de  15.-  sur  chaque  montre  d'une  gamme  1  et 
un  bénéfice  de  8.-  sur  chaque  montre  de  gamme  2  dans  le  cadre  d'un  nouveau  projet 
stratégique. 

Pour  satisfaire  à  la  demande  des  vendeurs  supposée,  la  production  journalière  de  montres  de 
gamme  1  devrait  se  situer  entre  30  et  80,  et  la  production  journalière  de  montres  de  gamme  2 
entre  10  et  30. 

Pour  maintenir  une  bonne  qualité,  le  nombre  total  de  montres  ne  devrait  pas  dépasser  80  par 
jour. 

Combien  de  montres  de  chaque  type  faudrait-il  fabriquer  quotidiennement  pour  réaliser  un 
bénéfice  maximum? 

Le  problème  est  à  résoudre  avec  MS  Office  Excel! 

Remarque:  Le  problème  peut  être  résolu  très  intuitivement  sans  le  solveur  mais  bon. . .  pour  le 
plaisir. . . 

Solution: 

Nous  construisons  par  exemple  la  feuille  suivante: 


A 

B 

C 

D 

E 

1 

2 

Quantité  gamme  1  : 

3 

4 

Quantité  gamme  2: 

5 

6 

Bénéfice  à  l'unité  gamme  1: 

15 

7 

8 

Bénéfice  à  l'unité  gamme  2: 

8 

9 

10 

11 

Total  quantité: 

0 

12 

13 

14 

Somme  bénéfice: 

0 

15 

avec  les  relations  suivantes: 
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A 

B 

c 

D 

1 

2 

Quantité  gamme  1  : 

1 

1  1 

1 

3 

4 

Quantité  gamme  2: 

1 

1  1 

1 

5 

6 

Bénéfice  à  l'unité  garr 

1 

fis  | 

1 

7 

8 

Bénéfice  à  l'unité  garr 

1 

|3  | 

1 

9 

10 

11 

Total  quantité: 

1 

|=D2+D4  | 

1 

12 

13 

14 

Somme  bénéfice: 

1 

|=D2*D6+D4*D8  | 

1 

■1  £T 

et  nous  configurons  le  solveur  ainsi: 


ce  qui  nous  donne: 


A 

B 

C 

D 

1 

2 

Quantité  gamme  1  : 

30 

3 

4 

Quantité  gamme  2: 

50 

et  qui  est  la  solution  du  problème! 
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12.1.15  Recherche  opérationnelle  dans  l’optimisation  de 
commandes 


Énoncé: 


Une  société  importatrice  de  café  achète  pense  acheter  des  lots  de  grains  de  café  en  vrac,  puis 
les  séparer  en  grains  de  premier  choix,  ordinaires  et  inutilisables. 

La  société  a  besoin  aura  besoin  pour  un  nouveau  projet  d'au  moins  280  tonnes  de  grains  de 
premier  choix  et  200  tonnes  de  grains  ordinaires. 

Elle  peut  acheter  des  grains  non  triés  à  volonté  chez  deux  fournisseurs  qui  contiennent  les 
pourcentages  suivants  de  grains  de  premier  choix,  ordinaires  et  inutilisables: 


Fournisseur 

1er  choix 

Ordinaire 

Inutilisable 

A 

20% 

50% 

30% 

B 

40% 

20% 

40% 

Chez  le  fournisseur  A  le  coût  à  la  tonne  est  de  125.-  et  chez  le  fournisseur  B  de  200.-. 

Trouvez  la  combinaison  optimale  permettant  de  satisfaire  les  besoins  tout  en  investissant  un 
minimum  d'argent. 

Solution: 

Nous  créons  la  feuille  suivante: 


O 

LD 

< 

D 

E 

F 

1 

Tonnes  de  grains  1  er  choix:  1 

280 

tonnes 

2 

3 

Tonnes  de  grains  ordinaires: 

200|tonnes 

4 

5 

6 

Fournisseur 

1  er  choix 

Ordinaire 

Inutilisable 

Coût  la  tonne 

Quantité? 

7 

A 

20% 

50%  30%  125.00 

8 

B 

40% 

20%  40%  200.00 

9 

10 

1  er  Choix  A: 

- 

11 

1  er  Choix  B: 

- 

12 

Somme: 

- 

13 

14 

Ordinaire  A: 

- 

15 

Ordinaire  B: 

- 

16 

Somme: 

- 

17 

13 

Coût  total:  | 

- 

■i  n 

Avec  les  relations  suivantes: 
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A 

B 

C 

D 

E 

F 

1 

Tonnes  de  grains  1er  choix: 

230 

tonnes 

2 

3 

Tonnes  de  grains  ordinaires: 

200 

tonnes 

4 

5 

6 

Fournisseur  1er  choix 

Ordinaire 

Inutilisable 

Coût  la  tonne 

Quantité? 

7 

A 

0.2 

0.5  0.3  125 

8 

B 

0.4 

0.2  0.4  200 

9 

10 

1  er  Choix  A: 

=B7*F7 

11 

1  er  Choix  B: 

=B3*F8 

12 

Somme: 

=SUM(B10:B1 1) 

13 

14 

Ordinaire  A: 

=C7*F7 

15 

Ordinaire  B: 

=C8*F8 

16 

Somme: 

=SUM(B14:B15) 

17 

18 

Coût  total:  | 

=F7*E7+F3*E3 

1Q 

i  r 

et  nous  configurons  le  solveur  ainsi: 


ce  qui  nous  donne: 


F 

6 

Quantité? 

7 

150 

B 

625 

et  qui  est  la  solution  du  problème! 
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12.1.16  Recherche  opérationnelle  dans  l’optimisation  de  la 
production 

Énoncé: 

Dans  une  entreprise,  nous  avons  les  données  suivantes: 


A 

B 

C 

D 

E 

iMois 

Production  Max 

Demande 

Coût  production 

Coût  inventaire 

1  Janvier 

120 

100 

60 

15 

1  Février 

120 

130 

60 

15 

B  Mars 

150 

160 

55 

20 

1  Avril 

150 

160 

55 

20 

B  Mai 

150 

140 

50 

20 

|jum 

150 

140 

50 

20 

Quelle  est  la  meilleure  manière  de  répartir  la  production  sur  les  6  mois  afin  de  minimiser  le 
coût  total  sachant  que  nous  avons  un  stock  initial  de  50  unités? 

Solution: 

Pour  trouver  la  solution,  dans  un  premier  temps,  nous  construisons  un  tableau  avec  la 
production  effective  et  les  stocks  effectifs  qui  seront  calculés: 


A 

B 

C 

D 

E 

F 

G 

H 

1 

Mois 

Production  Max 

Demande 

Coût  production 

Coût  inventaire 

Production  Effective 

Stock  Effectif 

Livrable 

2 

Janvier 

120 

100 

60 

15 

0 

0 

=50+F2-G2 

3 

Février 

120 

130 

60 

15 

0 

0 

=F3+G2-G3 

4 

Mars 

150 

160 

55 

20 

0 

0 

=F4+G3-G4 

5 

Avril 

150 

160 

55 

20 

0 

0 

=F5+G4-G5 

6 

Mai 

150 

140 

50 

20 

0 

0 

=F6+G5-G6 

1 

Juin 

150 

140 

50 

20 

0 

0 

=F7+G6-G7 

Ensuite,  nous  devons  aussi  écrire  la  fonction  de  coût  à  optimiser: 


A 

B 

C 

D 

E 

F 

G 

H 

î 

Mois 

Production  1  Demande 

Coût  produc 

Coût  invents  Production  I 

Stock  Effect  Livrable 

■ 

Janvier 

120 

100 

60 

15 

0 

0 

Février 

120 

130 

60 

15 

0 

0 

4 

Mars 

150 

160 

55 

20 

0 

0 

5 

Avril 

150 

160 

55 

20 

0 

0 

6 

Mai 

150 

140 

50 

20 

0 

0 

7 

Juin 

150 

140 

50 

20 

0 

0 

8 

50 

0 

0 

0 

0 

0 


Fonction  économique:  =SOMMEPROD(D2:D7;F2:F7)+SOMMEPROD(E2:E7;G2:G7) 


Ensuite,  nous  lançons  le  solveur  avec  les  paramètres  suivants: 
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et  nous  obtenons: 


A 

B 

C 

D 

E 

F 

G 

H  1 

1 

Mois 

Production  Max 

Demande 

Coût  production 

Coût  inventaire 

Production  Effective 

Stock  Effectif 

Livrable 

2 

Janvier 

120 

100 

60 

15 

80 

30 

100 

3 

Février 

120 

130 

60 

15 

120 

20 

130 

4 

Mars 

150 

160 

55 

20 

150 

10 

160 

5 

Avril 

150 

160 

55 

20 

150 

0 

160 

6 

Mai 

150 

140 

50 

20 

140 

0 

140 

7 

Juin 

150 

140 

50 

20 

140 

0 

140 

8 

9 

Fonction  économique: 

43450 

et  voilà  pour  un  MRP-0  (Material  Requirements  Planning). 
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12.1.17  Recherche  opérationnelle  dans  l’optimisation  des 
priorités 


Énoncé: 

Un  employé  à  une  série  de  tâches  indépendantes  à  exécuté  et  pour  lesquelles  les  informations 
suivantes  lui  sont  communiquées  par  son  système  informatique: 


Délais  en  jours  (à  partir  d'aujourd'hui) 


1 

2 

3 

4 

5 

6 


9 

1 

8 

18 

9 

6 


32 

29 

22 

21 

37 

28 


Nous  souhaiterions  savoir  quel  doit  être  l'ordonnancement  des  tâches  afin  de  minimiser  le 
retard  du  travai  (si  retard  il  y  a...). 

Comme  il  y  a: 

6!  =  720 


combinaisons  possibles,  nous  n'allons  pas  faire  cela  à  la  main... 

Solution: 

D'abord,  il  faut  oublier  de  trouver  une  solution  et  cela  ne  sera  pas  possible  avec  MS  Excel 
2007  ou  antérieur...  car  il  y  manque  dans  le  solveur  une  contrainte  nommée  "tous  différents". 
Nous  utiliserons  donc  MS  Excel  2010. 

Pour  résoudre  ce  problème  avec  MS  Excel  2010,  nous  pouvons  d'abord  préparer  un  tableau  du 
type  suivant  quelques  lignes  plus  bas  dans  la  même  feuille: 
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A 

B 

C 

D 

E 

1 

ID  Tâche 

Jours 

Délais  en  j 

jours  (à  partir  d'aujourd'hui)  | 

1 

1 

9 

32 

2 

7 

29 

4 

3 

8 

22 

4 

18 

21 

5 

9 

37 

6 

6 

28 

8 

9 

1  Ordonnancement  Jours 

Somme 

Délai  en  jours . . .  Retard  cumulé 

10 

i 

9 

9 

32 

0 

11 

2 

7 

16 

29 

0 

12 

3 

8 

24 

22 

2 

13 

4 

18 

42 

21 

21 

14 

5 

9 

51 

37 

14 

15 

6 

6 

57 

28 

29 

16 

Somme:  66 

où  l'idée  est  d'avoir  dans  le  tableau  en  haut  l'ordonnancement  original  (pour  en  garder  une 
trace  et  comparer  le  avant/après)  et  en  bas  le  tableau  optimisé. 

Voici  les  formules  classiques  explicites  du  deuxième  tableau: 


A 

B 

C 

D  I 

9 

Ordonnancement 

Jours 

Somme 

Délai  en  jours . . .  Retard  cumulé 

10 

1 

=INDEX(ÎB$2:$B$7;A10;1) 

=B10 

=MDEX(SC£2:£C£7;A10;1)  =SI(C10-D10<0;0;C10-D10) 

11 

2 

=MDEX(tBÎ2:ÎB$7,Al  1;1) 

=C 1 0+B 1 1 

=ÜEDEX(£C£2:SCS7;A11,1)  =SI(C11-D11<0;0;C11-D11) 

12 

3 

=MDEX(SBÎ2:$B$7;A12;1) 

=C1 1+B12 

=MDEX(SCS2:SCS7;A12;1)  =SI(C12-D12<0;0;C12-D12) 

13 

4 

=MDEX(£B$2:$B$7;A13;1) 

=C 1 2+B 1 3 

=ÜEDEX($C£2:tCt7;A13;l)  =SI(C13-D13<0;0;C13-D13) 

14 

5 

=INDEX(SB$2:$BS7;A14;1) 

=C13+B14 

=INDEX($C$2:$C$7;A14;1)  =SI(C14-D14<0;0;C14-D14) 

15 

6 

=MDEX(ÎB$2:$B$7;A15;1) 

=C14+B15 

=MDEX(£C£2:£C£7;A15;1)  =SI(C15-D15<0;0;C15-D15) 

16 

Somme  =SOMME(E10:E15) 

Et  ensuite  nous  lançons  le  solveur  avec  l'algorithme  évolutionnaire  (normalement  ce  problème 
a  peu  de  chances  de  trouver  une  solution  avec  l'algorithme  GRG  non  linéaire,  mais  nous 
constatons  que  MS  Excel  2010  en  trouvera  quand  même  une,  car  nous  le  soupçonons  d'utiliser 
quand  même  l'algorithme  évolutionnaire): 
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Ce  qui  donne: 


A 

B 

C 

D 

E 

9 

1  Ordonnancement  Jours 

Somme 

Délai  en  jours. . . 

Retard  cumulé 

10 

2 

7 

7 

29 

0 

11 

6 

6 

13 

28 

0 

12 

3 

3 

21 

22 

0 

13 

1 

9 

30 

32 

0 

14 

5 

9 

39 

37 

2 

15 

4 

13 

57 

21 

36 

16 

Somme: 

38 

Et  il  ne  faut  pas  être  surpris  si  pour  l'alorithme  évolutionnaire,  à  chaque  exécution,  et  dans  le 
cas  particulier  présent,  l'ordre  des  4  premières  tâches  peut  être  permuté  puisqu'elles 
n'influencent  pas  sur  le  résultat  final  quel  que  soit  leur  ordonnancement. 
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12.1.18  Corrélation  des  compétences 

s 

Enoncé: 

Ouvrez  le  fichier  Tests.mpj  qui  contient  les  points  obtenus  par  des  employés  qui  ont  passé  des 
tests  de  compétences  (techniques  de  communication  +  statistiques)  dans  une  entreprise 
d'ingénierie  (chaque  ligne  correspondant  à  un  employé): 


'ÿjjMinitab  -  Sans  titre  -  [Feuille  de  travail  1 


Jj3]x| 


Nous  souhaiterions  savoir  si  les  compétences  sont  corrélées  et  si  nous  obtenons  le  même 
résultat  qu'avec  MS  Excel. 

Solution: 

Nous  allons  dans  le  menu  Stat/Statistiques  élémentaires/Corrélation: 
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^>Minitab  -  Sans  titre  -  [Feuille  de  travail  1 


g£ü  a  &  ni  ^  l 


A  -1=1 


44  £ 


"3^1  ^ 


Cl 


C2 


information 


10 


12 


13 


14 


15 


statistiques 


Fichier  Edition  Données  Cale  stat  Graphique  Editeur  Outils  Fenêtre  Aide 

Afficher  les  statistiques  descriptives. . . 

Régression 
ANOVA 

DOE  (plan  d'expériences) 

Cartes  de  contrôle 
Outils  de  la  qualité 
Fiabilité/Survie 
Multivarié 

Série  chronologique 
lableaux 

Tests  non  paramétriques 
Analyse  exploratoire  des  données 
Puissance  et  effectif  de  l'échantillon  ► 


10.50 


8.75 


2.00 


12.50 


11.00 


15.50 


10.50 


11.50 


7.00 


14.00 


10.00 


7.50 


9.50 


9.00 


12.50 


16 


14 


10 


14 


18 


11 


12 


14 


12 


12 


12 


15 


13 


14 


Stocker  des  statistiques  descriptives.. 
S  ;  Récapitulatif  graphique. . . 

1Z  Test  Z  à  1  échantillon... 

Test  t  à  I échantillon... 

2t  Test  t  à  Z  échantillons... 

t«t  Test  t  pour  données  appariées. . . 

IP  1  proportion... 

2P  2  proportions... 

g1  P  Test  de  Poisson  à  1  échantillon. . . 

sZp  Test  de  Poisson  à  2  échantillons. . . 

(T2  1  variance... 

U: 


-1*1*1 


COV  Covariance... 


Test  de  normalité... 


yj  Test  d'adéquation  de  l'ajustement  pour  Poisson. . . 


Cl  2 


C13 


16 


16.50 


13 


17 


17.00 


12 


18 


14.50 


16 


19 


9.50 


J 


11  50 


in 


Calculer  les  coefficients  de  corrélation  du  moment  produit  de  Pearson 


Nous  avons  alors: 


Ce  qui  nous  donne  dans  la  fenêtre  de  session: 
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^  Minitab  -  Sans  titre 

Fichier  Edition  Données  Cale  5tat  Graphique  Editeur  Outils  Fenêtre  Aide 

*  m  £  <S>  f  m  J  €  •  B  ©  S  1  *®  B 1  B[ÜIH  1  ■ 

f*  I  “S  “I  dAd  [fi  ^  & 

jr  dS>|  *  y  +  p  S  ||  zl\ x  | Q, IJ  *  T  a  o  \  »  La  ta 

^LQjxj 

Q 

Session 

■ 

J 

Corrélations  :  information;  statistiques 

Corrélation  de  Pearson  de  information  et  statistiques  =  0.398 

.iJJ  ifi 

B 

Feuille  de  travail  1  *** 

n 

Cl 

C2 

C3 

C4 

C5 

CG 

C7 

CB 

C9 

CIO 

Cil 

Cl  2 

C13 

cd 

information 

statistiques 

i 

10.50 

8.75 

2.00 

12.50 

11.00 

15.50 

10.50 

16 

2 

14 

3 

10 

4 

5 

5 

14 

G 

18 

7 

LL 

11 

ifl 

l 

m  g 

Feuille  de  travail  en  cour 

rs  :  Feuille  de  travail  1 

Ce  qui  correspond  bien  au  R  que  donne  MS  Excel  (puisque  ce  dernier  donne  le  R2  il  faut 
prendre  la  racine  carré  du  coefficient  de  corrélation  de  MS  Excel  pour  voir  que  cela  est  bien 
conforme). 

Donc  ce  n'est  pas  parce  qu'un  employé  est  bon  avec  la  statistique  qu'il  est  bon  avec 
l'informatique. 
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12.1.19  Matrice  des  corrélations 


Un  projet  est  composé  de  10  tâches  et  8  ressources  y  participent.  Nous  avons  listé  dans  une 
table  à  double  entrée  qui  participait  à  quoi: 


où  le  "1"  signifie  "présent  sur  la  tâche  et  le  "0"  l'inverse... 

Faites  une  analyse  de  la  corrélation  pour  regrouper  les  personnes  dans  des  équipes  ad  hoc  en 
utilisant  MS  Excel. 

Solution: 

Nous  allons  dans  le  menu  Outils/Utilitaire  d'analyse  de  MS  Office  Excel  et  choisissons 
l'option  Corrélation : 


Vient  alors  une  boîte  de  dialogue  qu'il  convient  de  remplir  comme  suit: 
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Ce  qui  donne  (nous  avons  mis  des  couleurs  pour  mettre  en  évidence  un  choix  de 
regroupement  arbitraire): 


A 

B 

C 

D 

E 

F 

G 

H 

1 

1 

Alain 

A  line 

Albert 

Alex 

Adel 

Arthur 

Anderson 

Vincent 

2 

Alain 

1 

3 

Aline 

-0.53452 

1 

4 

Albert 

0. 801 784 

-0.42857 

1 

5 

Alex 

-0.40825 

-0.32733 

-0.32733 

1 

6 

Adel 

-0.40825 

0.218218 

-0.32733 

-0.25 

1 

7 

Arthur 

1 

-0.53452 

0.301784 

-0.40825 

-0.40825 

1 

8 

Anderson 

-0.53452 

0.047619 

-0.42857 

0.763763 

-0.32733 

-0.53452 

i 

9 

Vincent 

-0.25 

0.356348 

-0.08909 

-0.40825 

0.612372 

-0.25 

-0.53452 

if 

Une  première  équipe  sera  donc  composée  de: 

-  Alain  (corrélé  +  avec  Albert),  Albert  (corrélé  +  avec  Arthur),  Arthur  (corrélé  avec  personne) 
Une  deuxième  équipe  par: 

-  Aline  (corrélée  +  avec  Adel),  Adel  (corrélé  +  avec  Vincent),  Vincent 
Une  troisième  et  dernière  équipe. . 

Alex  (corrélé  +  avec  Anderson),  Anderson  (corrélé  avec  plus  personne. . .) 

12.2  Exemples  en  finance 

J'ai  rassemblé  ici  quelques  exemples  que  je  considère  que  le  minimum  minimorum  que  doit 
connaître  un  responsable  de  projet  en  termes  de  finance  de  base  associé  à  la  gestion  de  projets 
et  ce  qui  l'entoure. 

Les  démonstrations  mathématiques  peuvent  toutes  être  trouvées  dans  mon  livre  électronique 
Mathématiques  appliquées. 
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12.2.1  Intérêts  simples 

* 

Enoncé: 

El.  Nous  avons  mis  2'500KF.-  durant  n  mois  sur  un  placement  à  5%/an  constant  en  intérêts 
simples  (nous  retirons  l'intérêt  chaque  mois  année  financer  un  projet!).  Quelle  est  la  durée  de 
ce  placement  si  le  capital  avec  les  retraits  successifs  se  monte  à  2'531.25KF.-? 

E2.  Nous  avons  mis  2'500KF.-  durant  3  mois  sur  un  placement  pour  finance  un  projet.  Quel 
est  le  taux  constant  de  ce  placement  si  le  capital  final  avec  les  retraits  successifs  se  monte  à 
2'531.25KF.-  en  intérêts  simples? 

E3.  Trouver  l'intérêt  simple  global  constant  des  trois  placements  suivants  pour  financer  des 
projets: 

{l'000KF.-;90  jours;3%/an}  {2'000KF.-;120  jours;3%/an}  {3'000KF.-;  170  jours;  3%/an} 

E4.  Nous  avons  mis  22'340KF.-  pendant  43  mois  sur  un  placement  à  1.5%/mois  en  intérêts 
simples  constants  pour  financer  un  projet  (nous  retirons  l'intérêt  chaque  mois  année  financer 
un  projet!).  Quel  est  le  capital  final? 

PS:  Voir  à  résoudre  les  exercices  dans  MS  Excel  (ou  autre  tableur)  en  utilisant  de  simples 
fonctions  et  l'Outil  Valeur  Cible. 

Solutions: 

S 1 .  Le  capital  d'une  épargne  C0  à  un  taux  t%  après  une  capitalisation  pendant  n  périodes  est 
défini  logiquement  par: 


Cn  —  Cq  (1  +  n  •  t%)  —  Cq  + / 


Nous  avons  donc  en  kilo-francs: 


2'531.25  =  2 '500(1  + 5%  -  n) 
2'531.25  -  2'500 


1 


n  = 


2 '500 -5% 


=  0.25  =  —  an  =  3mois 
4 


S2.  Nous  réutilisons  la  relation  définie  précédemment  et  procédons  à  de  l'algèbre  élémentaire 
toujours  en  kilo-francs: 


2'531.25-2500 

2'500-3 


=  0.05  =  5% 


S3.  L'intérêt  global  est  donné  par  la  méthode  des  diviseurs  fixes: 


I  = 


iYjcknk 


k= 1 


Nous  avons  alors  en  kilo-francs: 
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/  =  0.03  •  (l'OOO  •  90/360  +  2'000- 120/360  +  3'000- 170/360)  =  70 

S4.  Nous  réutilisons  ici  la  définition  de  l’intérêt  simple  nous  avons  alors  toujours  en  kilo- 
francs: 


Cn  =  C0  (1  +  n  ■  t%)  =  22 ' 340  •  (1  +  43  •  1 .5%)  =  36749.3 
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12.2.2  Taux  géométrique  moyen 


* 

Enoncé: 


Une  entreprise  projet  voit  son  taux  de  rendement  interne  annuel  augmenter  de  2%  la  première 
année,  1.5%  la  deuxième,  3%  la  troisième,  0.5%  la  quatrième,  6%  la  cinquième,  0%  la 
sixième.  Quelle  est  son  taux  d'augmentation  moyen  sur  6  ans? 

Solutions: 

Le  piège  serait  d'utiliser  la  moyenne  arithmétique.  Il  faut  utiliser  ici  la  moyenne  géométrique: 


ce  qui  donne  immédiatement  dans  MS  Excel  (ou  autre  tableur): 


=MOYENNE.GEOMETRIQUE(102%;101.5%;103%;100.5%;106%;100%)=102.15% 
alors  que  la  moyenne  arithmétique  donnerait: 


=MOYENNE  (102%;101.5%;103%;100.5%;106%;100%)=102.17% 


ce  qui  peut  paraître  peu  mais  sur  des  millions  de  francs  ou  des  milliards  cela  fait  assez  vite  un 
somme  d'argent  non  négligeable! 
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12.2.3  Taux  proportionnel  et  moyen  sur  intérêts  simples 


Énoncé; 


El.  Un  projet  à  un  taux  de  rendement  interne  annuel  constant  de  12%.  Votre  direction  vous 
demande  de  calculer  le  taux  mensuel  proportionnel  au  taux  annuel  de  12%. 

E2.  Un  projet  à  un  taux  de  rendement  interne  trimestriel  constant  de  12%.  Trouver  le  taux 
mensuel  proportionnel  au  taux  semestriel  de  3%? 

E3.  Afin  de  financer  un  projet  votre  entreprise  à  diversifier  une  partie  de  ses  fonds  propres 
dans  trois  placements  différents  à  taux  annuel  garanti  constants  géré  par  trois  instituts 
financiers  différents  pendant  une  durée  déterminée.  Nous  avons: 

{ 1  '000KF.-;90 jours;3% }  {2'000KF.-;120 jours;4%)  {3'000KF.-;170 jours;5%} 

quel  est  le  taux  annuel  moyen  des  trois  placements? 

Solutions: 

SI.  Nous  avons  selon  la  définition  de  l'intérêt  simple: 


C0(l  +  teq%-n)  =  C0(l  +  t%) 


Nous  avons  alors: 


S2.  Selon  le  même  principe  qu'avant  nous  avons: 


t%  3% 


—  =  0.5% 
6 


S3.  Nous  appliquons  le  raisonnement  suivant: 


k  k 


T- 1<>, 


t= 1  r=l 


k 


t= 1 


Nous  avons  alors  en  kilo-francs: 


1000  •  3%  •  90  /  360  +  2000  •  4%  •  120  /  360  +  3000  •  5%  •  170  /  360 
1 000  •  90  /  360  +  2000  -120/360  +  3000  -170/360 


=  0.045  =  4.5% 
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12.2.4  Investissements  composés 


Enoncés: 

El.  Nous  avons  aujourd'hui  un  capital  de  3'582.15KF.-  pour  un  investissement  effectué  il  y  a 
6  ans  à  3%  d'intérêt  composé  l'an.  Quel  était  le  montant  initial  de  cet  investissement? 


E2.  Le  capital  d'un  investissement  a  doublé  en  20  ans.  Quel  est  le  taux  d'intérêt  composé 


annuel  correspondant? 

E3.  Votre  entreprise  a  placé  50'000KF.-  à  2.5%.  Elle  a  retiré  son  capital  investi  quand  celui-ci 
s'est  monté  à  53'000KF.-.  Quelle  a  été  la  durée  du  placement? 

E4.  Imaginons  que  vous  devez  voir  pour  un  ensemble  d'investissements  donnés  combien  vous 
aurez  d'intérêt  après  un  nombre  donné  d'années.  Créez  des  simulations  déterministes  avec 
l'Outil  Table  de  MS  Excel  (ou  autre  tableur). 

Solutions: 

SI.  Nous  savons  que  l'intérêt  composé  est  donné  trivialement  par: 


cn=c0a+t%r 


Donc: 


3'582.15 


°  a +t%y  a+3%)6 

Dans  MS  Excel  (ou  autre  tableur)  cela  donne  en  kilo-francs: 

=VA(3%;6;0;-3582.15;0)=2'999 

S2.  De  par  la  relation  de  l'intérêt  composé: 

i  =  n - 1  =  ^2-1  =  3.526% 


Dans  MS  Excel  (ou  autre  tableur)  cela  donne: 

=TAUX(20;0;-1;2;0) 

Ce  qui  correspond  si  on  avait  un  capital  final  Cn  et  inital  Co  à: 

=TAUX(20;0;-1;C„/C0;0) 

S3.  De  par  la  relation  de  l'intérêt  composé  nous  avons  en  kilo-francs: 
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■ 


log(z  + 1)  log(2.5%  +  1) 


Dans  MS  Excel  (ou  autre  tableur): 


=NPM(2.5%;0;-50000;53000;0)=2.35 


S4.  Il  serait  aisé  de  résoudre  cet  exercice  à  la  main  mais  un  peu  long  et  ennuyeux  quand 
même.  Nous  allons  alors  utiliser  l'outil  "Table"  de  MS  Excel  (ou  autre  tableur): 


La  méthode  est  simple:  on  créé  dans  une  feuille  MS  Excel  (ou  autre  tableur)  la  zone  suivante 
et  on  utilise  la  fonction  VC(  ). 


A 

B 

C 

D 

E 

F 

1 

Capital 

SFr.  5'000. 00 

2 

Taux 

11% 

3 

Périodes 

12 

4 

5 

=VCfB2;B3;0;-B1  ;Ü) 

12 

18 

24 

30 

36 

6 

5000.00 

7 

10000.00 

3 

15000.00 

9 

20000.00 

10 

25000.00 

11 

30000.00 

12 

35000.00 

13 

40000.00 

14 

45000.00 

15 

50000.00 

Ensuite  de  sélectionner  la  zone  A5  à  Fl 5  et  d'aller  dans  le  menu  Données  et  de  sélectionner 
l'option  Table  et  d'y  faire  la  sélection  suivante: 


et  de  valider  par  OK  pour  obtenir: 


SFr.  17'492.25 

12 

18 

24 

30 

36 

5000.00 

17492.25 

32717.76 

61195.78 

114461.48 

214090.42 

10000.00 

34984.51 

65435.53 

122391.57 

223922.97 

428180.35 

15000.00 

52476.76 

98'1 53.29 

183587.35 

343384.45 

642271 .27 

20000.00 

69969.01 

130871.06 

244783.13 

457845.93 

856361 .69 

25000.00 

87461 .26 

163588.82 

305978.91 

572307.41 

1070452.12 

30000.00 

104953.52 

196306.59 

367174.70 

686768.90 

1 284542.54 

35000.00 

122445.77 

229024.35 

428370.48 

801230.38 

1 498632.96 

40000.00 

139938.02 

261742.12 

489566.26 

915691.86 

1712723.39 

45000.00 

157430.28 

294459.88 

550762.05 

1030153.35 

1926813.81 

50000.00 

174922.53 

327177.65 

61 1 957.83 

1144614.83 

2140904.23 
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12.2.5  Taux  équivalents  sur  intérêts  composés 

Enoncés: 

El.  Dans  le  cadre  du  placement  d'un  fond  pour  financer  un  projet  futur,  une  banque  vous 
propose  un  taux  annuel  composé  de  12%.  Calculez  le  taux  mensuel  composé  équivalent  et 
refaites  le  calcul  inverse. 

E2.  Dans  le  cadre  du  placement  d'un  fond  pour  financer  un  projet  futur,  une  banque  vous 
propose  un  taux  mensuel  composé  de  12%.  Calculez  le  taux  trimestriel  équivalent  et  refaites 
le  calcul  inverse. 

Solutions: 

SI.  Nous  savons  que  par  définition: 


Cn  =  C0  (1  +  tn  %) 


n 


il  convient  alors  de  trouver: 


C0(l  +  t„%)"=C0(l  +  t%) 
=>  tn%  =  (l  +  t%)lln  -1 
=>*%  =  (!+*„%)"  -î 


il  vient  alors: 


tn  %  =  (1  + 12%)1/12  - 1  =  0.949% 


S2.  Le  principe  est  identique: 


t%  =  (l  +  l%)3 -1  =  3.03% 
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12.2.6  Taux  moyen  équivalent  composé 

s 

Enoncé: 

En  utilisant  l'outil  "valeur  cible"  de  MS  Excel  (ou  autre  tableur)  résolvez  l'équation  ci- 
dessous  afin  de  trouver  le  taux  moyen  équivalent  des  capitalisations  à  intérêt  composé  du 
tableau  suivant: 


Placement 

Durée 

Taux  1 

l'OOOKF.- 

1  an 

3% 

2'000KF.- 

2  an 

4% 

3'000KF.- 

3  an 

5% 

C1r”1+C2r”2+...  +  Ckrxkk  =  C^l+xf  +  C2(\+T)*2  +...  +  Ck(l+T)xk 


Astuce:  posez  x=l+T 

Solution: 

Dans  MS  Excel  (ou  autre  tableur),  nous  écrivons  dans  la  cellule  A2  en  kilo-francs: 
=1000*A1A1+2000*A1A2+3000*A1A3-1000*(1+3%)A1-2000*(1+4%)A2-3000*(1+5%)A3 


et  avec  l'outil  valeur  cible  de  MS  Excel  (ou  autre  tableur)  nous  définissons: 


Nous  trouvons  alors  Al=1.0459  et  donc  7=4.59% 
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12.2.7  Emprunt  Indivis  à  échéance  fixe 

s 

Enoncé: 

Un  emprunt  de  l'OOOKF.-  à  10%  l'an  doit  être  remboursé  à  l'échéance  au  bout  de  4  ans  pour 
l'achat  d'une  machine  nécessaire  au  bon  déroulement  d'un  projet. 

Etablir  le  tableau  d'amortissement  et  déterminer  le  coût  du  crédit. 

Solutions: 

Rappel: 

Chaque  année  l'annuité  comprend  uniquement  la  part  d'intérêt.  La  dernière  année,  l'annuité 
comprend  l'intérêt  ainsi  que  la  totalité  du  remboursement  de  l'emprunt. 

Etat  de  la  dette  (capital  emprunté): 


Ck=C  Vk 


Remboursement  (amortissement): 


A  =4 


0  si  k  <  n 
C  si  k  =  n 


Annuité: 


A  4  +  A 


Intérêt: 


4  =  w>ck 

SI.  Le  tableau  d'amortissement  est  alors  le  suivant  en  kilo-francs: 


Période 

Etat  de  la  dette 

Amortissement 

Amort.  Cumulé 

Intérêt 

Annuité 

k 

ck 

Rk 

Sk 

h 

Ak 

i 

1000 

0 

0 

100 

100 

2 

1000 

0 

0 

100 

100 

3 

1000 

0 

0 

100 

100 

4 

1000 

1000 

1000 

100 

1100 

Le  coût  du  crédit  représente  la  somme  des  intérêts  soit  400KF.- 
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12.2.8  Emprunt  Indivis  à  amortissements  constants 

s 

Enoncé: 

Un  emprunt  de  l'OOOKF.-  à  10%  l'an  est  remboursé  par  amortissement  constant  en  4  ans  pour 
l'achat  d'une  machine  nécessaire  au  bon  déroulement  d'un  projet.  Etablir  le  tableau 
d'amortissement  et  déterminer  le  coût  du  crédit. 

Solution: 

Rappel: 

Le  montant  annuel  remboursé  est  constant.  Les  relations  sont  alors  données  par: 


=  C-k- 
n 


=  —  (1  +  n  -  k) 
n 


SK-k- 

4=^q 

■4  =  +  4 

SI.  Le  tableau  d'amortissement  est  alors  le  suivant: 


Période 

Etat  de  la  dette 

Amortissement 

Amort.  Cumulé 

Intérêt 

Annuité 

k 

ck 

Rk 

Sk 

4 

Ak 

i 

1000 

250 

250 

100 

350 

2 

750 

250 

500 

75 

325 

3 

500 

250 

750 

50 

300 

4 

250 

250 

1000 

25 

275 

Le  coût  du  crédit  représente  la  somme  des  intérêts  soit  250KF.- 

Le  remboursement  est  périodiquement  plus  difficile  à  assumer  qu'un  emprunt  indivis  à 
échéance  fixe  mais  il  y  l'avantage  de  ne  pas  devoir  débourser  une  grosse  quantité  d'argent  à  la 
toute  dernière  période.  Le  désavantage  est  que  l'annuité  n'est  pas  constante. 

L'idéal  serait  un  système  dont  l'annuité  est  constante  et  dont  l'amortissement  est  progressif. 
C'est  que  nous  allons  toute  de  suite  faire. 
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12.2.9  Emprunts  à  annuités  constantes 

Enoncés: 

El.  Soit  un  emprunt  à  20'000KF.-  à  5%  l'an  sur  10  ans  pour  financer  un  projet,  calculer  le 
payement  annuel  selon  un  système  à  annuités  constantes  formellement  et  avec  MS  Excel  (ou 
autre  tableur). 

E2.  Avec  MS  Excel  (ou  autre  tableur),  déterminez  la  valeur  de  la  4eme  période  de 
l'amortissement  et  des  intérêts. 

E3.  Calculer  avec  MS  Excel  (ou  autre  tableur)  la  somme  d'intérêts  payés  entre  la  période  1  et 
10  (total  des  intérêts)  et  5  et  10  ainsi  que  la  somme  de  l'amortissement  entre  les  mêmes 
périodes. 

Solutions: 

SI.  Soit  un  emprunt  à  20'000.-  à  5%  l'an  sur  10  ans,  calculer  le  payement  annuel  selon  un 
système  à  annuités  constantes  formellement  et  avec  MS  Excel  (ou  autre  tableur). 

Nous  avons  selon  les  relations  données: 


A  =  A, 


c_ 

n\ 


c 


1-v” 


t% 


20000 

1 - — lï 

(1  +  5%)*° 

5% 


2590.09.  - 


dans  MS  Excel  (ou  autre  tableur),  il  suffit  d'écrire: 

=VPM(5%;10;20000;0;0)=-2590.09.- 
S2.  Pour  ce  faire,  dans  MS  Excel  (ou  autre  tableur),  il  suffit  d'écrire: 

=PRINCPER(5%;4;  10;20000;0;0)=  - 1  '840.73 
=INTPER(5%;4;10;20000;0)=-749.36 
la  somme  des  deux  donnant  toujours  l’annuité. 

Cela  permet  de  construire  (si  désiré).  Le  tableau  suivant: 
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Période 

Etat  de  la  dette 

Intérêt 

Amortissement 

Annuité 

1 

-20'000.00 

rooo.oo 

-1 '590.09 

-2'590.09 

2 

-18'409.91 

920.50 

-1 '669.60 

-2'590.09 

3 

-16740.31 

837.02 

-1753.08 

-2'590.09 

4 

-14’987.24 

749.36 

-l'840.73 

-2'590.09 

5 

-13’146.51 

657.33 

-l'932.77 

-2'590.09 

6 

-11'213.74 

560.69 

-2'029.40 

-2'590.09 

7 

-9184.34 

459.22 

-2130.87 

-2'590.09 

8 

-7'053.46 

352.67 

-2'237.42 

-2'590.09 

9 

-4’8 16.04 

240.80 

-2'349.29 

-2'590.09 

10 

-2'466.75 

123.34 

-2'466.75 

Coût  du  crédit: 

5’900.91 

-20'000.00 

S3.  Calculer  avec  MS  Excel  (ou  autre  tableur)  la  somme  d'intérêts  payés  entre  la  période  1  et 
10  (total  des  intérêts)  et  5  et  10  ainsi  que  la  somme  de  l'amortissement  cumulé  entre  les 
mêmes  périodes. 

Pour  cela,  il  suffit  d'écrire: 

=CUMIPMT (5  %  ;  1 0;20000;  1  ;  10;0)=-5’900.9 1 

=CUMIPMT (5  %  ;  10;20000;5  ;  1 0;0)=-2'394.04 

=CUMPRINC(5%;10;20000;5;10;0)=  -13'146.51 

=CUMPRINC(5  %  ;  1 0;20000;  1  ;  1 0;0)=-20'000 
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12.2.10  Amortissement  linéaire 

Enoncés: 

El.  Une  machine  valant  initialement  20'000.-  perdra  18'000.-  de  sa  valeur  en  6  ans  (soit  90% 
de  sa  valeur).  Quel  amortissement  annuel  faut-il  enregistrer  selon  la  méthode  de 
l'amortissement  linéaire  afin  de  savoir  quelle  sera  sa  valeur  pour  la  revente  en  fonction  de 
l'année  de  clôture  du  projet  estimé  à  4  ans? 

Calculer  cette  valeur  à  la  main  et  avec  MS  Excel  (ou  autre  tableur). 

E2.  Calculer  le  pourcentage  de  perte  en  valeur  par  an  de  la  machine  précédente  à  la  main  et 
avec  MS  Excel  (ou  autre  tableur). 

Solutions: 

Rappel: 

La  valeur  de  l'immobilisation  est  diminuée  d'un  montant  annuel  constant  durant  sa  durée  de 
vie  selon: 


A  =  A  = 


n 


SI.  L'amortissement  annuel  se  calcule  donc  selon: 


20000-2000 


avec  MS  Excel  (ou  autre  tableur),  nous  pouvons  écrire: 

=AMORLIN(20000;2000;6)=3000.- 

Donc  après  4  ans  la  machine  pourra  théoriquement  être  revendue  ou  cédée  pour: 

20000  -  4 • 3000  =  8000.  - 


S2.  Ce  calcul  est  facile  (il  est  normalement  inutile  de  faire  usage  d'Excel  (ou  autre  tableur) 
pour  une  telle  chose): 


%  = 


20000-2000 

6 

20000 


3000 

20000 


=  15% 


ou  dans  MS  Excel  (petite  tricherie. . .): 

=TAUX.  INTERETS  1 .0 1 . 1 999;0 1 .0 1 .2005  ;20000;2000;4)=- 1 5  % 
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12.2.11  Amortissement  arithmétique  dégressif 

s 

Enoncé: 

Un  bien  d'une  valeur  initiale  de  20'000.-  doit  être  amorti  en  6  ans  selon  l'amortissement 
arithmétique  dégressif  à  2'000.  Quel  amortissement  annuel  faut-il  enregistrer  selon  la  méthode 
de  l'amortissement  arithmétique  dégressif  afin  de  savoir  quelle  sera  sa  valeur  pour  la  revente 
en  fonction  de  l'année  de  clôture  du  projet  estimé  à  4  ans?  Etablir  le  tableau  d'amortissement. 

Solutions: 

Rappel: 

La  valeur  de  l'immobilisation  décroît  inversement  à  l'ordre  des  années: 

,  n-k+\fTr  Tr ■. 

A  =  — - — {K-K) 

Nous  utilisons  la  fonction  SYD  dans  MS  Excel  (ou  autre  tableur)  dont  la  syntaxe  est: 

SYD(valeur  initiale, valeur  finale, nombre  de  périodes, période) 

SNous  construisons  le  tableau  selon  la  relation  indiquée  où: 

n  =  6,S5  =l  +  2  +  3  +  4  +  5  +  6  =  21,V0  =  20000.-,  V5  =2000.- 

Ainsi: 

-•18000  =  5142.14.- 
21 

-•18000  =  4285.71.- 
21 

-•18000  =  3428.57.- 
21 

-•18000  =  2571.42.- 
21 

-•18000  =  1714.28.- 
21 

-•18000  =  857.14.- 
21 

Le  tableau  d'amortissement  est  donc  le  suivant: 


A  = 
A  = 
A  = 
A  = 
A  = 
A  = 
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Date 

Amortissement 

Valeur 

0 

20'000 

1 

5142.86 

14*857.14 

2 

4'285.71 

10*571.43 

3 

3'428.57 

7142.86 

4 

2'57 1 .43 

4'571.43 

5 

1714.29 

2'857.14 

6 

857.14 

2'000.00 

Avec  MS  Excel  (ou  autre  tableur),  il  est  possible  de  déterminer  les  valeurs  d'amortissement 
avec  la  relation  SYD  comme  indiqué,  par  exemple: 

=SYD(75000;0;5;3)=15'000.- 

Cette  méthode  d'amortissement  est  favorable  par  rapport  à  la  précédente  au  niveau  des  impôts 
pour  une  entreprise  dans  certaines  situations.  Mais  il  faut  se  référer  au  cadre  juridique  du  pays 
d'activité  pour  savoir  s'il  est  autorisé  de  l'utiliser  ou  non. 
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12.2.12  Amortissement  dégressif  géométrique 

Enoncés: 

Une  nouvelle  machine  dont  la  valeur  neuve  est  de  20'000.-  a  une  durée  de  vie  prévue  sur 
6  années  avec  une  valeur  résiduelle  de  2'000.-.  Quel  va  être  la  perte  de  valeur  à  chaque 
période  et  la  valeur  amortie  réelle? 

Effectuez-le  avec  MS  Excel  (ou  autre  tableur)! 

Solutions: 

Rappel: 

Nous  démontrons  que  la  valeur  d'amortissement  à  une  période  k  est  donnée  par: 


A  =  K 


Jt-1 

xK; 


k  \ 


f  y  Y» 
_ 


Le  tableau  d'amortissement  se  construit  à  la  main  à  l'aide  des  valeurs  suivantes: 


Vn  =2 '000.-,  Y,  =  2000,  n  =  6 


Par  exemple  pour  A4  (4eme  année)  nous  avons 


A4  =20 '000 


f  4-1 

2 '000  Yî 


4  \ 


(  t non  A  k  (  2'000  Ye 


20 '000 


20' 000 


=  2014.93. 


La  somme  des  amortissements  est  donc  d'environ:  18'005.13.- 


Dans  MS  Excel  (ou  autre  tableur)  pour  obtenir  l'amortissement  A4  ,  nous  utilisons  la  fonction: 

=DB(20000;2000;6;4;12)=2014.93 
Nous  pouvons  alors  facilement  construire  le  tableau  suivant: 
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Date  k 

Amortissement  A* 

Valeur  résiduelle 

0 

0 

20’000 

1 

6'380.00 

13'620 

2 

4'344.78 

9'275.22 

3 

2'958.79 

6'3 16.42 

4 

2'014.93 

4'301.49 

5 

1 '372.19 

2'929.31 

6 

934.45 

1-994.86 

Cette  méthode  implique  un  amortissement  encore  plus  rapide  que  la  précédente.  Elle  est 
imposée  légalement  (au  même  titre  que  les  méthodes  précédentes)  dans  la  législation  de 
certains  pays.  Il  faut  donc  aussi  bien  se  renseigner  au  préalable. 
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12.2.13  Valeur  actuelle  nette 


Enoncés: 

El.  Un  entreprise  vous  propose  vous  céder  une  machine  pour  un  investissement  de  2'000KF.- 
(correspondant  à  sa  valeur  résiduelle)  dans  un  projet  ayant  un  cash-flow  qui  double  chaque 
période  sur  une  base  de  400KF.-  assurée  pendant  3  périodes  alors  que  le  taux  moyen 
géométrique  d'intérêt  du  marché  est  de  5%.  L'investissement  est-il  intéressant  sous 
l'hypothèse  qu'il  n'y  aura  pas  de  frais  annexes? 

E2.  Une  entreprise  souhaite  acquérir  une  nouvelle  machine  valant  6'OOOKF.-  ce  qui  devrait 
permettre  d'abaisser  les  coûts  de  production  de  l'OOOKF.-  par  an  durant  5  ans.  On  estime  que 
dans  5  ans,  la  valeur  résiduelle  de  cette  machine  sera  de  3'000KF.-.  Doit-on  acheter  cette 
machine  si  cet  investissement  peut  être  financé  par  un  emprunt  à  10% 

E3.  Une  entreprise  pharmaceutique  veut  développer  un  nouveau  médicament.  Elle  opte  pour 
deux  stratégies: 

a.  Investir  1  milliard  de  frs  et  vendre  le  médicament  immédiatement.  Dans  ce  cas,  l'entreprise 
estime  recevoir  500  millions  de  frs  à  la  fin  de  l'année,  400  dans  2  ans  et  300  millions  dans  3 
ans. 

b.  Développer  le  médicament  plus  lentement,  c'est-à-dire  investir  200  millions  maintenant, 
200  millions  dans  1  an  et  recevoir  300  millions  à  la  fin  des  années  2  et  3 

Quelle  stratégie  est  à  envisager  si  l'entreprise  peut  se  financer  à  5%  l'an? 

Solutions: 

Rappel: 

La  valeur  actuelle  nette  (différence  entre  la  valeur  actuelle  des  dépenses  et  entrées  futures)  est 


donnée  par: 


S 1 .  Pour  réponde  à  la  question  nous  savons  donc  que  nous  aurons  pour  les  3  périodes 
respectivement: 


400KF.-,  800KF.-  et  1600KF.- 


de  cash-flow 

Pour  obtenir  chacune  de  ces  trois  sommes  à  3%  pendant  1,  2  et  3  périodes  respectives  nous 
aurions  dû  épargner  une  somme  initiale  de  en  kilo-francs: 


Y  ck  _  400  800  1600 

h.  (i + t%Ÿ  ~  a + 5 %y +  a + 5%)2  +  a + 5%)3 


=  2'488.72. - 
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La  somme  à  capitaliser  est  donc  plus  grande  que  la  somme  de  2'000KF.-  à  investir  que  nous 
propose  notre  ami.  Le  ou  VAN  est  donc  de  positif  et  égal  en  kilo-francs  à: 

VAN  =  2'488.72  -  2000  =  488.72 


Pour  obtenir  ce  résultat  sous  MS  Excel  (ou  autre  tableur)  il  suffit  d'écrire: 

=-2000+ V  AN  (5  %  ;400 ; 8 00;  1 600) 

S2.  Nous  appliquons  le  même  raisonnement  que  précédemment  en  kilo-francs: 


VAN  = 


C, 


+  - 


V 


-f(i +t%y  (i +t%f 


n 

-n=Z 


1000 


+  ■ 


3000 


^(i+5%r  a+5%r 


-6000  =  -346.6 


Le  VAN  étant  négatif,  nous  n'avons  pas  intérêt,  selon  ce  critère,  à  acheter  cette  machine. 

Dans  MS  Excel  (ou  autre  tableur)  il  faut  écrire: 

=-6000+VAN(  1 0%;  1000;  1 000;  1 000;  1000 ;4000) 

S3.  Une  entreprise  pharmaceutique  veut  développer  un  nouveau  médicament.  Elle  opte  pour 
deux  stratégies: 

a.  Investir  1  milliard  de  frs  et  vendre  le  médicament  immédiatement.  Dans  ce  cas,  l'entreprise 
estime  recevoir  500  millions  de  frs  à  la  fin  de  l'année,  400  dans  2  ans  et  3000  millions  dans  3 
ans. 

b.  Développer  le  médicament  plus  lentement,  c'est-à-dire  investir  200  millions  maintenant, 
200  millions  dans  1  an  et  recevoir  300  millions  à  la  fin  des  années  2  et  3 


Quelle  stratégie  est  à  envisager  si  l'entreprise  peut  se  financer  à  5%  l'an? 
Pour  la  stratégie  (a)  nous  avons: 


VAN 

a 


500  400  300 

(l  +  5%y  (l  +  5%)2  (l  +  5%)3 


-1000  =  98.15  mios.- 


Pour  la  stratégie  (b)  il  faut  bien  distinguer  la  partie  retour  sur  investissement  (cash-flow)  de  la 
partie  investie: 


VANb 


300  300 

(l  +  5%)2  (l  +  5%)3 


200  + 


200 

(l  +  5%y. 


=  140.78  mios.- 


Selon  ce  critère,  la  stratégie  b  est  financièrement  plus  intéressante. 
Dans  MS  Excel  (ou  autre  tableur)  il  faut  écrire: 

=-200+VAN(5%;-200;300;300) 
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12.2.14  Valeur  actuelle  nette  (tabulaire) 

Enoncés: 

Considérons-nous  en  avenir  certain  (comme  pour  tous  les  exercices  précédents)  avec  un 
investissement  initial  unique  de  ÎO'OOOKF.-  pour  un  projet  avec  un  taux  d'actualisation 
constant  de  10%  et  un  cash-flow  parfaitement  périodique  de  3'250KF.-,  3750KF.-,  4'250KF.-, 
4750KF.-. 

1.  Calculer  le  VAN  avec  MS  Excel  (ou  autre  tableur)  en  établissant  le  tableau  d'actualisation 
correspondant 

2.  Représenter  graphiquement  les  cash-flows  avec  MS  Excel  (ou  autre  tableur). 

Solutions: 

1.  Nous  avons  le  tableau  d'actualisation  en  kilo-francs: 


A 

B 

C 

D 

E 

1 

Année 

Action 

Cash-Flow 

C.A. 

C.F.A. 

2 

0 

Investissement 

-ÎO'OOO.OO 

1.00 

-ÎO'OOO.OO 

3 

1 

Entrée 

3'250.00 

0.91 

2'954.55 

4 

2 

Entrée 

3750.00 

0.83 

3'099. 17 

5 

3 

Entrée 

4'250.00 

0.75 

3'193.09 

6 

4 

Entrée 

4750.00 

0.68 

3'244. 3 1 

7 

SOMME 

F.N.T: 

6'000.00 

F.N.T.  A: 

2'491.12 

8 

9 

VAN: 

2'491. 12 

où  dans  le  tableau  ci-dessus  F.N.T.  signifie  "Fond  Net  de  Trésorerie"  ("net  cash  flow"  en 
anglais),  F.N.T.A.  "Fond  Net  de  Trésorerie  Actualisé",  C.A.  "Coefficient  d' Actualisation"  et 
C.F.A.  "Cash-Flow  Actualisé". 

Soit  sous  forme  explicite: 


A 

B 

C 

D 

E 

1 

Année 

Action 

Cash-Flow 

C.A. 

C.F.A. 

2 

0 

Investissement 

-10000 

1 

-10000 

3 

1 

Entrée 

3250 

=1/(1+10%) 

=C3*D3 

4 

2 

Entrée 

3750 

=1/(1+10%)A2 

=C4*D4 

5 

3 

Entrée 

4250 

=1/(1+10%)A3 

=C5*D5 

6 

4 

Entrée 

4750 

=1/(1+10%)A4 

=C6*D6 

7 

SOMME 

F.N.T: 

6'000.00 

F.N.T.A: 

=SUM(E2:E6) 

8 

9 

VAN: 

=-10000+van(10°/o;C3;C4;C5;C6) 
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Nous  remarquerons  au  passage  qu'à  partir  de  la  3  année,  l’investissement  initial  est  remboursé. 
On  parle  alors  de  période  de  payback. 

2.  Graphiquement  nous  avons: 
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12.2.15  Taux  de  rendement  interne  (Internai  Rate  of 
Return) 

Enoncés: 

A  l'aide  de  MS  Excel  (ou  autre  tableur)  résoudre  les  exercices  suivants: 

El.  Une  entreprise  vous  propose  de  vendre  sa  machine  pour  un  investissement  de  2'000KF.- 
(correspondant  à  sa  valeur  résiduelle)  dans  un  projet  ayant  un  cash-flow  qui  double  chaque 
période  sur  une  base  de  400KF.-  assurée  pendant  3  périodes  alors  que  le  taux  moyen 
géométrique  d’intérêt  du  marché  est  de  5%  par  période.  Calculer  le  TRI  (taux  de  rendement 
interne)  à  partir  duquel  le  VAN  est  nul. 

E2.  Une  entreprise  souhaite  acquérir  une  nouvelle  machine  valant  6'OOOKF.-  ce  qui  devrait 
permettre  d'abaisser  les  coûts  de  production  de  l'OOOKF.-  par  an  durant  5  ans.  On  estime  que 
dans  5  ans,  la  valeur  résiduelle  de  cette  machine  sera  de  3'000KF.-.  Calculer  le  TRI  (taux  de 
rendement  interne)  à  partir  duquel  le  VAN  est  nul. 

E3.  Une  entreprise  pharmaceutique  veut  développer  un  nouveau  médicament.  Elle  opte  pour 
deux  stratégies: 

a.  Investir  1  milliard  de  frs  et  vendre  le  médicament  immédiatement.  Dans  ce  cas,  l'entreprise 
estime  recevoir  500  millions  de  frs  à  la  fin  de  l'année,  400  dans  2  ans  et  300  millions  dans  3 
ans. 

b.  Développer  le  médicament  plus  lentement,  c'est-à-dire  investir  200  millions  maintenant, 
200  millions  dans  1  ans  et  recevoir  300  millions  à  la  fin  des  années  2  et  3 

Calculer  le  TRI  (taux  de  rendement  interne)  à  partir  duquel  le  VAN  est  nul  pour  chaque 
stratégie 

E4.  Une  machine  coûte  ÎO'OOO.-.  Elle  permet  de  générer  un  profit  net  de  1  '500.-  par  an  durant 
14  ans  avec  une  valeur  résiduelle  nulle.  Calculer  le  TRI  de  cet  investissement. 

E5.  Calculez  le  VAN  et  le  TRI  d'un  projet  qui  a  amené  à  investir  400.-  MF  au  départ  et  qui  a 
rapporté  100.-  MF  la  première  année,  où  nous  avons  investi  150.-  MF  la  deuxième  année,  qui 
nous  a  fait  gagner  200.-  MF  la  troisième  année  et  500.-  MF  la  quatrième  sur  un  marché  où  le 
taux  géométrique  moyen  est  de  10  %. 

Solutions: 

Rappel:  le  taux  de  rentabilité  interne  (TRI)  est  le  taux  d'actualisation  pour  lequel  le  VAN  du 
projet  est  nulle.  Il  s'agit  en  fait  de  trouver  le  taux  t%  tel  que: 

C  C  C  V 

VAN  = - ^  + - ^— +  ...  + - n- - + - 2 - Vn  =0 

i+t%  a +t%)2  a +t%y  a  +  t%y 

C  C  C  V 

y  =  Cl  + _ ZI _ +  + _ Zil _ + _ _ » _ 

0  i  +  t%  (i +t%f  (i +t%y  (i  +  t%y 

Il  existe  une  fonction  spéciale  pour  cela  dans  MS  Excel,  la  fonction  TRI: 
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=  TRI  (V0;Cl;C2;...',Cn;  [ estimation ]  ) 


SI.  Nous  avons  déjà  partiellement  résolu  cet  exercice  précédemment  où  nous  avions  écrit: 


VAN  = 


400 

(1+5  %y 


800 

(l  +  5%)2 


1600  -  -  2000  =  2 ' 488.72.  - 
(l  +  5%)3 


Il  nous  suffit  alors  de  poser: 


400 

(1  +  t%? 


+  ■ 


800 


■  +  • 


1600 


a +t%y  a +t%y 


-2000  =  0 


et  de  trouver  le  bon  t%.  Pour  cela  nous  allons  recourir  au  logiciel  standard  MS  Excel  en 
écrivant  (attention  à  mettre  V0  toujours  en  premier  et  ensuite  à  l'ordre  chronologique  des  cash- 
flow!)  la  formule 


=TRI(  { -2000 ;400 ; 800 ;  1 600  }  )=  1 5 . 1 1 7  % 

52.  Une  entreprise  souhaite  acquérir  une  nouvelle  machine  valant  6'000.-  ce  qui  devrait 
permettre  d'abaisser  les  coûts  de  production  de  l'000.-  par  an  durant  5  ans.  On  estime  que 
dans  5  ans,  la  valeur  résiduelle  de  cette  machine  sera  de  3'000.-.  Calculer  le  TRI  (taux  de 
rendement  interne)  à  partir  duquel  le  VAN  est  nul. 

Nous  procédons  de  manière  identique  en  saisissant  la  formule: 

=TRI(  { -6000;  1 000;  1 000;  1 000;  1 000;4000 }  )=8 . 1 7  % 

53.  Une  entreprise  pharmaceutique  veut  développer  un  nouveau  médicament.  Elle  opte  pour 
deux  stratégies: 

a.  Investir  1  milliard  de  frs  et  vendre  le  médicament  immédiatement.  Dans  ce  cas,  l'entreprise 
estime  recevoir  500  millions  de  frs  à  la  fin  de  l'année,  400  dans  2  ans  et  300  millions  dans  3 
ans. 

Nous  appliquons  le  même  raisonnement  que  pour  la  solution  précédente,  en  écrivant  la 
formule: 


=TRI(  { - 1000;500;400;300 }  )=  10.65  % 

b.  Développer  le  médicament  plus  lentement,  c'est-à-dire  investir  200  millions  maintenant, 
200  millions  dans  1  an  et  recevoir  300  millions  à  la  fin  des  années  2  et  3 

Nous  appliquons  le  même  raisonnement  que  pour  la  solution  précédente: 

=TRI({-200;-200;300;300})=22.47  % 

S4.  Une  machine  coûte  10'000.-.  Elle  permet  de  générer  un  profit  net  de  l'500.-  par  an  durant 
14  ans  avec  une  valeur  résiduelle  nulle.  Calculer  le  TRI  de  cet  investissement  (sol.  =  1 1.89%) 

De  même  que  précédemment,  nous  écrivons: 
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=TRI({-10000;1500;1500;1500;1500;1500;1500;1500;1500;1500;1500;1500;1500;1500;1500)=11.89% 


S5.  Même  principe  qu'avant: 

=-400+VAN  (10%;100;-150;200;500)=58.71 


et: 


=TRI(  { -400;  100;- 1 50;200;500 }  )=  14.26% 
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12.2.16  Valeur  actuelle  nette  espérée 


* 

Enoncé: 


Soit  un  projet  dont  les  cash-flows  annuels  possibles  sont  estimés  comme  suit  (chiffres  en 
millier  de  francs): 

Année  1:  20,  40,  60,  80  /  Année  2:  40,  60,  70,  90  /  Année  3:  30,  40,  60,  80 

Avec  des  possibilités  respectives  de  Pl  =  20%,  P2  =  30%,  P2  =  30%,  P4  =  20% 

El.  Sachant  que  le  montant  de  l'investissement  est  de  ÎOO'OOO.-  et  que  le  taux  du  marché  est 
de  12%  déterminer  l'espérance  et  l'écart- type  du  VAN. 

E2.  Déterminer  l'espérance  du  TRI 

Solution: 

SI.  L'espérance  du  VAN  est  donnée  par: 


E(VAN ) 


(20 -0.2 +  40 -0.3 +  60 -0.3 +  80 -0.2)  |  (40 -0.2 +  60 -0.3 +  70 -0.3 +  90 -0.2) 


d  +  12%)1 

(30- 0.2  + 40 -0.3 +  60 -03 +  80 -0.2) 

(1  +  1 2%)3 


(1  +  12%) 


=  50  •  0.893  +  65  •  0.797  +  52  •  0.712  - 100  =  33.479.  -  kF 


Soit  dans  MS  Excel: 


=-100+NPV(12%;50;65;52) 


Pour  le  calcul  de  la  variance  nous  avons  (en  utilisant  la  relation  de  Huyghens): 
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V(VAN)=^- 


ncf) 


=z 


'ZPtf-E(Çi) 


tïci+i%r  ti  ci+i°/or 

2 O2  ■  0.2  +  402  •  0.3  +  602  0.3  +  S02  ■  0.2-502 


4  O2 

■  0.2 +  602 

Cl  +  12%)1 

0.3  +  702  •  0.3  +  902 

■0.20-652 

302 

■  0.2  +402 

(1  +  1 2%)2 

0.3  +  602  •  0.3  +  802 

■  0.20  -  502 

(1  +  12%)3 


_  2920-502  (  4490-602  (  3  0  2  0  -  522  _  420  !  265  ,  316 

~  G  +  12%)1  (1  +  12%)2  (1  +  1 2%) 3  ~  ri  +  12%)1  (1  +  1 2%) 2  (1+1 2%) 3 

=  375  +211.205  +  224.992  =  811.18  kF 


et  donc: 


c  =  VB11.18  =  RACINE(VAN(420;  265;  316))  =  28.48  kF 

Entre  deux  ou  plusieurs  projets  concurrents,  nous  retenons  celui  dont  l'espérance 
mathématique  de  la  VAN  est  la  plus  élevée  et  l'écart-type  de  la  VAN  la  plus  faible.  Ne  reste 
plus  qu'à  faire  de  l'inférence  statistique. . . 

S2.  Une  fois  les  calculs  du  VAN  effectués  le  calcul  du  TRI  espéré  est  simple. 

Pour  l'espérance  nous  avons  alors: 

=TRI({-100;50;65;52})=30.415% 

12.2.17  VAN  et  TRI  apériodiques 

s 

Enoncé: 

A  l'aide  de  MS  Excel  (ou  autre  logiciel)  calculons  le  VAN  et  le  TRI  d'un  projet  qui  a  amené  à 
investir  400.-  MF  le  01.01.2008,  et  qui  a  rapporté  100.-  MF  le  31.12.2008,  où  nous  avons 
investi  150.-  MF  le  31.12.2009,  qui  nous  a  fait  gagner  200.-  MF  la  31.12.2010  et  500.-  MF  le 
31.12.2011  où  le  taux  géométrique  moyen  du  marché  est  de  10%  l'an. 

Solution: 

Nous  construisons  le  tableau  suivant: 


A 

B 

C 

D 

E 

F 

1 

Date 

01.01.2008 

31.12.2008 

31.12.2009 

31.12.2010 

31.12.2011 

2 

Flux 

-400 

100 

-150 

200 

500 

3 

4 

VAN 

58.71 

TRI 

14.26% 

et  les  relations  correspondantes  sont: 
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A 

B 

C 

D 

E 

F 

1 

Date 

01.01.2003 

31.12.2003 

31.12.2009 

31.12.2010 

31.12.2011 

2 

Flux 

-400 

100 

-150 

200 

500 

3 

4 

VAN 

=VAN.PAIEMENTS(10%;B2:F2;B1:F1) 

TRI 

=TRI.  PAIEMENTS  (B2:  F2;  B1  :  Fl) 
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12.2.18  Analyse  probabiliste  des  ventes  et  de  la  production 

s 

Enoncé: 

Une  analyse  temporelle  (A.S.T.)  des  ventes  (V)  d'une  entreprise  par  période  fixe  donnée 
suivent  une  loi  Normale  de  moyenne  E(V)  =  60'000  unités  et  d'écart-type  cr(V)  =  25'400 . 

-  Les  charges  variables  s'élèvent  à  85%  du  chiffre  d'affaire. 

-  Les  charges  fixes  s'élèvent  à  915'000  .- 

-  Le  prix  de  vente  unitaire  est  de  150.- 

Afin  de  savoir  si  nous  pouvons  investir  de  manière  pérenne  dans  la  R&D  de  nouveaux  projets 
nous  souhaiterions  savoir: 

El.  L'espérance  mathématique  et  l'écart-type  de  la  loi  R  du  résultat? 

E2.  La  probabilité  cumulée  d'être  au-delà  ou  égal  au  seuil  de  rentabilité 

E3.  L'objectif  de  ventes  tel  qu'il  ait  au  moins  2  chances  sur  3  de  l'égaliser  ou  dépasser. 

Solutions: 

Le  résultat  aléatoire  est: 

R  =  15015%V-915'000  =  22.5  V-915'000 

en  effet  les  charges  fixes  prennent  85  %  du  chiffre  d’affaires  calculé  en  multipliant  P  =  150.  - 
par  le  chiffre  aléatoire  V  des  ventes  et  de  plus  il  faut  soustraire  les  charges  fixes  de  915’000.- 

S 1 .  L’espérance  mathématique  du  résultat  est  en  utilisant  la  propriété  de  linéarité  de 
l'espérance: 


E(R)  =  22.5  •  E(V)  -  915 '000  =  22.5  •  60 '000  -  915 '000  =  435  ’  000.  - 
et  l'écart-type  du  résultat  est  en  utilisant  les  propriétés  de  ce  moment: 

cr(R)  =  22.5  •  cr(V)  =  571 '000.  - 
S2.  Le  seuil  de  rentabilité  est  défini  par: 

R  =  15015%V-915’000>0 

Puisque  les  ventes  suivent  une  loi  Normale,  la  rentabilité  aussi  suit  une  loi  Normale  de 
paramètres: 


<j(R)  =  571' 000.  —  et  E(R)  =  435 '000.- 

La  question  est  donc  de  savoir  la  probabilité  cumulée  que  P(R  >  0) .  Dans  MS  Excel,  il  suffit 
de  saisir: 


=1-LOI.NORMALE(0;435000;571000;1)=77.62% 
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S 3.  Il  s'agit  donc  de  calculer  P 


f 


>\ 


V>- 

V  3y 


c'est-à-dire  de  mettre  dans  MS  Excel  (ou  autre 


tableur): 


=LOI.NORMALE.INVERSE(  1-2/3;  435000;  571000)=  189054.71 
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12.2.19  Modèle  de  Wilson 


Enoncés: 

Dans  le  cadre  d'un  projet  de  développement  d'entreprise,  vous  gérez  un  entrepôt  dont  la 
demande  de  réfrigérateurs  est  estimée  à  600  unités  par  mois  en  moyenne. 

Le  coût  de  lancement  (ou  de  passation)  s'élève  à  3'000.-  par  commande  (de  lot). 

Le  coût  de  possession  moyen  du  stock  est  estimé  à  90.-  par  unité  en  stock  et  par  mois. 

Déterminez  à  l'aide  du  modèle  de  Wilson: 

1 .  La  quantité  (lot)  économique  optimale  qui  minimise  le  coût  de  passation 

2.  La  rotation  annuelle  du  stock 

3.  La  couverture  du  stock 

4.  Le  coût  minimal  annuel  de  gestion  de  ce  stock 

5.  Le  coût  de  stockage  que  nous  devrions  avoir  pour  atteindre  les  600  unités  comme  quantité 
économique  optimale. 

Remarque:  Une  année  sera  supposée  faire  12  mois  et  30  jours  (ouvrés) 

Solution: 

Il  convient  d'abord  d'identifier  les  informations.  Nous  avons  donc: 


N  =  600  et  Cs  =  90.  -  et  CL=  3000.  - 


S 1 .  Le  lot  économique  optimal  est  donné  par: 


Donc  il  faudrait  éviter  que  les  clients  commandent  une  quantité  en-dessous  de  cette  valeur  qui 
minimise  donc  le  coût  total  de  possession. 


S2.  La  rotation  annuelle  des  stocks  est  définie  comme  le  nombre  de  fois  que  le  lot  optimal  est 


consommé  sur  une  période.  Ainsi  dans  notre  cas  le  lot  optimal  est  consommé  3  fois  par  mois, 
soit: 


36  fois  par  année. 


53.  Nous  avons  donc  600  unités  par  mois  soit  sur  un  mois  de  30  jours:  20  unités  quotidiennes 
qui  sortent.  Et  comme  le  lot  économique  est  de  200,  la  couverture  du  stock  est  de: 

10  jours. 

54.  Le  coût  minimal  de  gestion  est  donné  pour  une  période: 
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N 

—  i 

Q 


+ 

(Q  „  3 

t%P 

=  —cL  + 

(Q  „  ) 

U  sJ 

U 

Q 

U  5  J 

C 


et  plus  précisément  par: 


ct  =— CL  + 

(Q 

—  +  Ss 

cs 

=  600  3000  + 

f 200  n  3 
- +  5, 

Qe 

U  'J 

200 

l  2  s) 

90 


Si  le  stock  de  sécurité  est  nul  alors  nous  avons: 


600 


200 


C,  = - 3000  + - 90  =  9000  +  9000  =  90  •  200  =  1 8 ' 000.  - 

*  200  2 


soit  sur  une  année: 


18'000  12  =  216'000 

ce  que  le  lecteur  peut  comparer  au  coût  de  gestion  de  gestion  sans  optimisation  du  lot 
économique. . .  il  verra  que  la  différence  est  absolument  non  négligeable! 

S5.  Il  s'agit  de  faire  un  peu  d'algèbre: 


Qe  = 


2  NCr 


c 


<£  =  N2 


2NÇl 

cs 


c. 


2Cl  _  2-3000 
N  ~  600 


12.3  Exemples  en  qualité 

J'ai  rassemblé  ici  quelques  exemples  que  je  considère  que  le  minimum  minimorum  que  doit 
connaître  un  responsable  de  projet  en  termes  de  qualité  de  base  associé  à  la  gestion  de  projets 
et  ce  qui  l'entoure.  Beaucoup  d'exercices  ont  été  repris  de  mon  livre  sur  le  logiciel  Minitab  (à 
ce  jour  mon  logiciel  préféré  de  gestion  statistique  de  la  qualité)  et  son  très  fortement  corrélés  à 
ce  qui  se  fait  dans  le  cursus  de  certification  Six  Sigma. 

Les  démonstrations  mathématiques  peuvent  toutes  être  trouvées  dans  mon  livre  électronique 
Mathématiques  appliquées. 

12.3.1  Tirage  non-exhaustif  (loi  binomiale) 

Enoncé: 

Pour  réaliser  le  montage  d'un  système  électronique,  nous  disposons  de  résistances  issues  d'une 
production  (très)  importante,  où  nous  savons  que  le  pourcentage  de  pièces  défectueuses  est  de 
30%  sur  toute  la  production  (Retour  d'expérience). 

Nous  devons  envoyer  l'OOO  résistances  à  un  client  d'une  production  journalière  de  ÎOO'OOO 
unités.  Celui-ci  accepter  le  lot  s'il  y  en  a  mois  ou  égal  à  324  de  défectueuses?  Quelle  est  la 
probabilité  cumulée  d'en  avoir  entre  0  et  324  au  vu  de  la  qualité  actuelle  de  la  production? 

Solution: 
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D'abord,  il  s'agit  d'appliquer  la  loi  binomiale  (tirage  non  exhaustif,  dont  l'ordre  n'est  pas  pris 
en  compte)  d'une  probabilité  cumulée. 


La  probabilité  d'en  avoir  moins  ou  égal  à  324  de  mauvaises  sur  les  l'OOO  est  de: 

=LOI.BINOMIALE(324;1000;30%;1)=95.38% 


Donc  il  y  a  aussi  une  probabilité  cumulée  de: 


l-95.38%=4.62% 


d'en  avoir  plus  de  325  de  mauvaises!  Ce  qui  est  très  mauvais  aussi  (on  pouvait  s'en  douter)! 

12.3.2  Acceptation/Rejet  de  lot  par  tirage  non-exhaustif 
(loi  binomiale) 

Enoncé: 

Dans  une  usine  de  production  un  client  externe  souhaite  un  lot  de  l'OOO  pièces. 

Nous  savons  qu'il  y  a  30%  de  la  production  (très  grosse  production  par  hypothèse!)  qui  est 
défaillante  à  cause  de  la  grande  complexité  des  pièces. 

Combien  de  pièces  devons-nous  lui  envoyer  pour  qu'il  y  ait  19  chances  sur  20  d'avoir  l'OOO  de 
bonnes  sachant  que  nous  n'avons  pas  l'infrastructure  ni  le  temps  pour  les  tester  toutes? 

Solution: 

Il  s'agit  dans  MS  Excel  d'écrire  la  formule  suivante: 


A 

1 

1000 

2 

=CRITERE.  LOI.  BINOMIALE(A1  ;  1-30%;  1-95%) 

D'activer  l'outil  Valeur  cible: 


ce  qui  donne: 


-1471  pièces 

Ainsi,  en  envoyant  1  '471  pièces  au  client,  il  a  bien: 

=LOI.BINOMIALE(47 1  ;  147 1  ;30%;  1  )=95 .64% 
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de  probabilité  cumulée  de  trouver  entre  0  et  471  pièces  défectueuses  dans  le  lot  d'envoi  de 
1471  pièces.  Il  n'aura  donc  que  5%  de  probabilité  cumulée  d'avoir  moins  de  1000  pièces 
bonnes  au  final! 

Par  ailleurs  le  responsable  qualité  chez  le  client  sera  donc  sûr  avec  95%  de  probabilité 
cumulée  que  l'acceptation  du  lot  est  ok  s'il  en  vérifie  au  moins  470  pièces  en  faisant  donc  le 
calcul  suivant: 


=CRITERE.LOI.BINOMIALE(1471;30%;95%)=470 


12.3.3  Probabilité  de  panne  (loi  binomiale) 

Enoncé: 

Nous  souhaitons  tester  l'alternateur  d'un  groupe  électrogène.  La  probabilité  de  défaillance  à  la 
sollicitation  de  ce  matériel  est  estimée  à  1  défaillance  pour  l'OOO  démarrages. 

Nous  décidons  d'effecteur  un  test  de  100  démarrages. 

El.  Quelle  est  la  probabilité  d'observer  exactement  1  panne  au  cours  de  ce  test? 

E2.  Quelle  est  la  probabilité  d'observer  plus  de  1  panne  au  cours  de  ce  test? 

Solution: 

SI.  Nous  avons: 


Pik  =  1  )  =  q 


N 


NI 


k\(N-k)\ 


k  N-k 

p  q 


100! 


1  !(100  —  1)  ! 


,  V/  ,  y9 

1 - =9% 

{  1000 


1000 


Soit  dans  MS  Excel: 


S2.  De  même: 


=LOI.BINOMIALE(  1  ;  1 00;  1/1000;0)=9% 


= 1  -LOI.BINOMIALE(  1  ;  100;  1/1000;  1  )=0.46% 


12.3.4  Tirage  exhaustif  (loi  hypergéométrique) 

Enoncé: 

Dans  une  petite  production  unique  d'un  lot  de  l'OOO  pièces  dont  nous  savons  (retour 
d'expérience)  que  30%  en  moyenne  sont  mauvaises  à  cause  de  la  complexité  des  pièces  par 
retour  d'expérience  de  pièces  similaires. 

El.  Nous  savons  qu'un  client  va  en  tirer  20  au  hasard  pour  décider  d'accepter  ou  de  rejeter  le 
lot.  Il  ne  rejettera  pas  le  lot  s'il  trouve  zéro  pièce  défectueuse  parmi  ces  20.  Quelle  est  la 
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probabilité  d'en  avoir  exactement  0  de  défectueuse? 

E2.  Nous  savons  qu'un  autre  client  va  en  tirer  20  au  hasard  pour  décider  d'accepter  ou  de 
rejeter  le  lot.  Il  ne  rejettera  pas  le  lot  s'il  trouve  une  quantité  inférieure  ou  égal  3  pièces 
défectueuses  parmi  ces  20.  Quelle  est  la  probabilité  cumulée? 

Solution: 

51.  D'abord,  il  s'agit  d'appliquer  la  loi  hypergéométrique  (tirage  exhaustif,  dont  l'ordre  n'est 
pas  pris  en  compte) 

Nous  allons  prendre  pour  ce  calcul  MS  Excel: 

=LOI.HYPERGEOMETRIQUE  (0;20;300;1000)=0.073% 

Donc  malheureusement  c'est  très  mauvais  pour  le  fournisseurs  car  en  d'autres  termes,  le  client 
à  plus  de  99%  de  probabilité  de  tomber  sur  une  ou  plusieurs  pièces  défectueuses! 

52.  Donc  MS  Excel  2007  et  antérieur: 

=LOI.HYPERGEOMETRIQUE  (0;20;300;1000)+  LOI.HYPERGEOMETRIQUE 
(1;20;300;1000)+  LOI.HYPERGEOMETRIQUE  (2;20;300;1000)+ 

LOI.HYPERGEOMETRIQUE  (3 ;20;300;  1000)= 10.47% 

ou  avec  MS  Excel  2010  et  ultérieur: 

=LOI.HYPERGEOMETRIQUE.N(3;20;300;1000;1)=10.47% 

Ce  qui  reste  médiocre  car  cela  signifie  que  cet  autre  client  a  en  gros  -90%  de  probabilité 
cumulée  de  tomber  sur  plus  de  3  pièces  défectueuses. 

12.3.5  Tirage  exhaustif/non-exhaustif  (loi  binomiale, 
hypergéométrique) 

Enoncé: 

On  souhaite  mettre  en  production  un  petit  développement  informatique  de  ÎO'OOO  lignes  de 
code.  Le  REX  (Retour  d'Expérience)  montre  que  la  probabilité  de  défaillance  est  de  1  bug 
pour  l'OOO  lignes  de  code. 

El.  On  teste  environ  15%  des  fonctions  du  logiciel  au  hasard  avant  l'envoi  au  client  (soit 
l'équivalent  de  l'500  lignes  de  code  «ÎO'OOO).  On  demande  quelle  est  la  probabilité 
d'observer  1  bug  et  de  comparer  la  valeur  donnée  par  la  loi  binomiale  et  hypergéométrique. 

E2.  On  teste  environ  50%  des  fonctions  du  logiciel  au  hasard  avant  l'envoi  au  client  (soit 
l'équivalent  de  5 '000  lignes  de  code).  On  demande  quelle  est  la  probabilité  d'observer  5  bugs 
et  de  comparer  la  valeur  donnée  par  la  loi  binomiale  et  hypergéométrique. 

Solution: 

SI.  Nous  calculons  d'abord  avec  la  loi  binomiale: 
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=LOI.BINOMIALE(1;1500;1/1000;0)=33.47% 


et  ensuite  avec  la  loi  hyper  géométrique: 

=LOI.HYPERGEOMETRIQUE  (1  ;  1500;  10;  10000)=34.75% 

Nous  voyons  donc  bien  que  conformément  à  la  théorie,  tant  que  le  tirage  n'est  pas  exhaustif 
les  deux  valeurs  sont  proches. 

S2.  Nous  calculons  d'abord  avec  la  loi  binomiale: 

=LOI.BINOMIALE(5;5000;1/1000;0)=17.55% 

et  ensuite  avec  la  loi  hyper  géométrique: 

=LOI.HYPERGEOMETRIQUE  (5;5000;10;10000)=24.62% 

Nous  voyons  donc  bien  que  conformément  à  la  théorie,  quand  le  tirage  est  exhaustif  les  deux 
valeurs  diffèrent. 

12.3.6  Réussites  avant  1er  échec  (loi  géométrique) 

Enoncé: 

Un  contrôle  de  qualité  long  terme  nous  a  permis  de  calculer  l'estimateur  de  la  proportion  p  des 
pièces  non-conformes  comme  valant  2%  à  la  sortie  d'une  ligne  de  production.  Quelle  est  la 
probabilité  cumulée  d'avoir  19  pièces  bonnes  avant  la  lere  défectueuse? 

Solution: 

Il  s'agit  de  calculer  en  utilisant  soit  la  loi  géométrique  (non  disponible  dans  MS  Excel): 

19  19  19 

P(k  <  19)  =  =  Z98%fe_l2%  =  31-87% 

k=\  k= 1  k= 1 

soit  en  utilisant  la  loi  binomiale  négative  cumulée  disponible  dans  MS  Excel  2010  (bon  cela  à 
peu  d'intérêt  d'en  faire  usage  pour  uniquement  une  "réussite"  mais  bon. . .  c'est  juste  à  titre  de 
comparaison): 


=LOI.BINOMIALE.NEG.N(19;1;0.02;1)=33.23% 
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12.3.7  Réussites  avant  n-ème  échec  (loi  binomiale  négative) 


Enoncé: 


Un  contrôle  de  qualité  long  terme  nous  a  permis  de  calculer  l'estimateur  de  la  proportion  p  des 
pièces  non-conformes  comme  valant  2%  à  la  sortie  d'une  ligne  de  production. 


El.  Nous  souhaiterions  calculer  la  probabilité  cumulée  d'avoir  200  pièces  bonnes  avant  que  la 


3ème  pièce  défectueuse  apparaisse. 

E2.  Quelle  est  l'espérance  du  nombre  de  pièces  bonnes  que  nous  aurons  avant  la  troisième 
pièce  non-conforme,  sachant  que  la  probabilité  d'une  pièce  non-conforme  est  de  2%? 

Solution: 

SI.  Avec  MS  Excel  2010  ou  ultérieur  en  français  il  vient  en  utilisant  la  loi  binomiale 
négative: 


=LOI.BINOMIALE.NEG.N(200;3;0.02;1)=77.35% 


Pour  comparer  avec  la  loi  binomiale,  demandons-nous  quelle  est  la  probabilité  cumulée  de 
tirer  198  pièces  non-défectueuses  parmi  201  avec  MS  Excel  2010  ou  ultérieur  en  français: 


=LOI.BINOMIALE.N((198;201;0.98;1)=76.77% 


S2.  Quelle  est  l'espérance  et  la  variance  du  nombre  de  pièces  bonnes  que  nous  aurons  avant  la 
troisième  pièce  non-conforme,  sachant  que  la  probabilité  d'une  pièce  non-conforme  est  de 


2%? 


E{R)  =  -  =  -£-  =  150 

p  2% 


et  pour  la  variance: 


12.3.8  Test  binomial  de  la  proportion 


Enoncé: 


Si  5%  de  la  production  annuelle  d'une  entreprise  est  défectueuse,  qu'elle  est  la  probabilité 


qu'en  prenant  un  échantillon  de  75  pièces  de  la  ligne  de  production  que  2%  ou  moins  soit 
défectueux? 

Solution: 

Nous  savons  que: 
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k-np 
yfnpq 

suit  une  loi  Normale  centrée  réduite  où  np  correspond  à  l'espérance  de  la  loi  binomiale  et 
■sjnpq  à  son  écart-type. 

Puisque  nous  travaillons  dans  cet  exercice  en  %  du  lot  total,  nous  travaillerons  non  pas  avec  la 
variable  binomiale  k  mais  avec: 


k'  = 


et  de  par  la  propriété  de  l'espérance,  nous  avons: 


\nj 


1 


1 


=  —E(k)  =  —  np  =  p 
n  n 


et  de  par  la  propriété  de  la  variance  nous  avons: 


y 


\nJ 


=  cr2  =  —V(k)  =  —npq  = 


n 


n 


pq_ 

n 


Nous  avons  alors: 


Z  = 


k'—  p 


Nous  avons  dès  lors: 


,,  0.02  -  0.05  ' 
0.05-0.95 


75 


La  probabilité  cumulée  correspondante  à  cette  valeur  de  la  variable  aléatoire  est: 

=NORMSDIST(- 1 . 1 9)= 1 1 .66% 

12.3.9  Écart-Moyen  VS  Écart-Type 

Enoncé: 

Soit  le  tableau  de  production  ci-dessous: 
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A 

B 

1 

Jour 

Production 

2 

i 

700 

3 

2 

850 

4 

3 

600 

5 

4 

575 

6 

5 

450 

7 

6 

900 

8 

7 

300 

9 

Total 

4375 

10 

Moyenne 

625 

Déterminer  avec  MS  Excel  l'écart-moyen: 


N 

Xk- H 

EM  -  — - 

N 


et  l'estimateur  de  maximum  de  vraisemblance: 


£(x;-x) 


G  — 


et  donner  leur  interprétation. 

Solution: 

SI.  Pour  1  'écart-moyen  nous  avons: 


A 

B 

c 

1 

Jour 

Production 

PM 

2 

1 

700 

75 

3 

2 

850 

225 

4 

3 

600 

25 

5 

4 

575 

50 

6 

5 

450 

175 

7 

6 

900 

275 

8 

7 

300 

325 

9 

Total 

4375 

1150 

10 

Moyenne 

625 

164.29 

qui  peut  être  obtenu  avec: 


=ECART.MOYEN(B2:B8)=164.29 
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Soit  en  d'autres  mots,  en  moyenne  164.29  éléments  produits  ont  dévié  de  la  moyenne  chaque 
jour  durant  la  semaine. 

S2.  L'estimateur  de  maximum  de  vraisemblance  (estimateur  sans  biais)  peut  lui  être  obtenu 
par: 


=ECARTYPE(B2:B8)=2 12.62 

en  termes  statistiques  nous  avons  alors  que  si  les  données  sont  distribuées  normalement  et  que 
les  erreurs  sont  dues  à  la  somme  d'une  multitude  de  petits  effets  (loi  normale)  alors  -68%  des 
valeurs  de  production  se  trouveront  à  ±212.62  autour  de  la  moyenne. 


12.3.10  Intervalles  de  qualité 

Enoncé: 

Les  tolérances  sur  les  valeurs  d'une  résistance  sont  en  10“3  [Q]  pour  la  tolérance  inférieure: 


7)  =  LSL  =  420 


et  pour  la  tolérance  supérieure: 


Ts  =  USL  =  720 


Ces  résistances  ont  une  valeur  qui  suit  une  loi  Normale  de  moyenne: 

ju  =  600- 10-3  [Q] 


et  d'écart-type: 


o-  =  1 20  -10“3  [Q] 

Quel  est  le  pourcentage  de  bonnes  résistances?  Soit  en  d'autres  termes,  la  probabilité  d'être 
entre  420  et  720? 

Solution: 

D'abord,  il  s'agit  d'appliquer  la  loi  de  Gauss. 

Nous  allons  prendre  pour  ce  calcul  MS  Excel: 

=LOI.NORMALE(720;600;120;1)-  LOI.NORMALE  (420;600;  120;  1)=77.45% 

12.3.11  Indices  de  fiabilité 


Enoncé: 

Une  machine  est  censée  travailler  24  heures  sur  24,  7  jours  sur  7.  Elle  a  tourné  jusqu'à 
aujourd'hui  pendant  5 '020  heures  mais  avec  2  arrêts  d'un  total  de  20  heures  (donc  inclus  dans 
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les  5'020  [h]).  Donnez  les  indicateurs  classiques  relativement  au  peu  d'informations 
communiquées. 

Solution: 


MTBF  =  — —  =  2510  [ h. ] 


MDT  =  —  =  10  [4] 


=  2500  [ h ] 


2 

MOTBF 


MOTBF  =  2500  g  9^Q% 


MOTBF  +  MDT  2500  +  10 


12.3.12  Défaillance  AMDEC  (loi  exponentielle) 


Enoncé: 

Soit  un  matériel  électronique  réparable,  nous  connaissons  le  taux  de  défaillance 
À  =  0.00001//?.  (soit  une  MTBF  de  ÎOO'OOO  heures). 

Trouver  la  probabilité  de  défaillance  entre  q  =  200 h.  et  t2  =  300 h.  sachant  que  celle-ci  suit 
une  loi  exponentielle  dans  le  cas  le  plus  général  qui  soit. 

Solution: 

Nous  savons  que: 


La  fonction  de  distribution  est  alors: 


Elle  suit  donc  une  loi  exponentielle! 


Nous  avons  alors  la  probabilité  de  défaillance: 

^2 


P(fj  <  D  <  t2)  =  j Âe~Àtdt  =  e~Àt'  =  0.001  =  0.1% 


Soit  avec  MS  Excel: 

=LOI.EXPONENTIELLE(300;0.0000 1  ;  1  )  -  LOI.EXPONENTIELLE  (200;0.00001;1)=0.1% 


Ingénierie  de  Gestion  de  projets 


506/547 


Vincent  ISOZ 


12.3.13  Défaillance  AMDEC:  MTTF  (loi  exponentielle) 

Enoncé: 

Un  composant  électrique  non  réparable  à  un  taux  de  défaillance  constant  de: 

1  =  2-10  ~6lh. 

Calculer  son  MTTF  (Mean  Time  To  Failure:  donc  il  s'agit  d'un  élément  non  réparable!)  dans 
les  500  premières  heures. 

Solution: 

Puisque  son  taux  de  défaillance  est  constant,  nous  devons  utiliser  la  loi  exponentielle  dont 
l'espérance  (MTTF)  est  donnée  par: 


MTTF  =  —  =  5  •  105  /î. 

1 

12.3.14  Tirage  avec  défaillance  temporelle  AMDEC  (loi  de 
Poisson) 

Enoncé: 

Un  processus  de  fabrication  produit  en  moyenne  3.84  éléments  défectueux  par  jour  (processus 
sous  contrôle  dont  la  moyenne  est  fixe  même  si  le  nombre  d'essais  est  très  grand). 

Quelle  est  la  probabilité  d'avoir  exactement  5  éléments  défectueux  dans  un  jour  pris  au 
hasard? 

Rappel:  La  loi  de  Poisson  est  la  loi  des  événements  rares! 

Solution: 

Etant  donné  les  informations  il  s'agit  d'utiliser  la  loi  de  Poisson: 

PI 5)  =  =  3MS  e~3M 

k\  5! 


Nous  avons  alors  avec  MS  Excel: 

=LOI.POISSON(5;3.84;0)=  14.95% 


12.3.15  Probabilité  de  panne  AMDEC  (loi  de  Poisson) 

Enoncé: 
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Sur  une  machine  de  production,  on  sait  qu'il  y  a  en  moyenne  1  panne  tous  les  4  mois  (20  jours 
ouvrés  par  mois).  Quelle  est  la  probabilité  cumulée  qu'il  y  ait  0  panne  lors  d'une  journée  de 
démonstration: 

Solution: 

Etant  donné  les  informations  il  s'agit  d'utiliser  la  loi  de  Poisson. 

Nous  avons  d'abord: 


u  = - =  0.0125  [panne!  jour] 

4-20 


Donc  il  vient: 


P(  0)  =  ^-e~M  = 
kl 


0.0125  -0.0125 

- e 

0! 


Nous  avons  alors  avec  MS  Excel: 

=LOI.POISSON(0;0.0125;1)=  98.75% 


12.3.16  Défaillance  AMDEC:  MTBF  (loi  exponentielle) 

Enoncé: 

Supposons  que  le  temps  en  mois  entre  l'arrêt  de  lignes  de  montage  d'une  production  ait  une 
valeur  MTBF  de  5  mois. 

El.  Quelle  est  la  constante  A  de  la  loi  exponentielle  qui  modélise  le  mieux  le  fonctionnement 
de  l'atelier. 

E2.  Quelle  est  la  probabilité  cumulée  que  la  ligne  de  production  s'arrête  à  nouveau  après  15 
mois  et  ou  après  5  mois  de  bon  fonctionnement? 

E3.  Quelle  est  la  probabilité  cumulée  que  la  ligne  de  fabrication  tombe  en  panne  dans  moins 
de  20  mois. 

E4.  Quelle  est  la  probabilité  cumulée  que  la  ligne  de  production  tombe  en  panne  entre  le  I0eme 
et  le  20ème  mois? 

Solution: 

SI.  Nous  avons: 


MTBF  =  5  =  -=>  A  =  0.2/ mois 
A 

S2.  Puisque  le  système  suit  une  loi  exponentielle: 

P(X  <  15)  =  e~15À  =  4.98% 
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Soit  dans  MS  Excel: 


=1-  LOI.EXPONENTIELLE(15;0.2;1)=4.98% 

et  pour  dans  les  5  mois: 

=1-LOI.EXPONENTIELLE(5;0.2;1)=36.7% 


S3.  C'est  simple: 


P(X  <  20)  =  1  -  P(X  >  20)  =  1  -  e_20A  =  98.17% 


Soit  dans  MS  Excel: 

=  LOI.EXPONENTIELLE  (20;0.2;1)=98.17% 

S4.  Il  suffit  de  calculer: 

P(10<X  <15)  =  P(X  <15)-P(X  <10)  =  (l-e~15À)-(l-e~lOÀ) 

=  95.02%  -  86.46%  =  8.55% 

Soit  dans  MS  Excel: 

=  LOI.EXPONENTIELLE  (15;0.2;1)-  LOI.EXPONENTIELLE  (10;0.2;1)=8.55% 

12.3.17  Défauts  dans  lots  (loi  Normale) 

Énoncé: 

Le  nombre  moyen  de  produits  défectueux  dans  une  ligne  de  production  sous  contrôle 
statistique  est  de  10.5  par  mois  avec  un  écart-type  de  2.5.  Quelle  est  la  probabilité  suivant  une 
loi  Normale  que  le  nombre  d'éléments  défectueux  choisis  aléatoirement  soit  inférieur  à  15. 

Solution: 

Il  suffit  de  calculer  avec  MS  Excel: 

=LOI.NORMALE(  1 5  ;  1 0.5  ;2.5  ;  1  )=96.47% 


12.3.18  Garantie  de  durée  de  vie  (loi  Normale) 

Un  fabricant  d'ampoules  suite  à  une  étude  observe  que  ses  ampoules  ont  une  durée  moyenne 
de  vie  de  250  heures  avec  un  écart-type  de  15  heures  suivant  une  loi  Normale  (ce  qui  serait 
inquiétant...).  Il  souhaiterait  sur  ses  emballages  indiquer  le  temps  de  vie  de  ses  ampoules  tel 
que  seulement  5%  de  celles-ci  se  trouvent  en-dessous  de  l'indication.  Quelle  est  la  durée  à 
indiquer? 

Solution: 

Il  suffit  de  calculer  avec  MS  Excel: 
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=  LOI.NORMALE.INVERSE  (5%;250;15)=225.325 


12.3.19  Moyenne  et  variance  de  variables  normalement 
distribuées 

Enoncé: 

Les  chaînes  de  production  d'une  société  ont  produit  des  pièces  pendant  4  semaines.  Chaque 
semaine,  la  moyenne  arithmétique  et  l'écart-type  sans  biais  d'une  côte  d'une  pièce  ont  été 
calculés  sur  la  base  de  distribution  normale.  A  la  fin  des  4  semaines  le  tableau  suivant  a  été 
obtenu: 


N°  Semaine 

Moyenne  ji] 

Ecart-type  <7, 

1 

20.5 

0.3 

2 

20.6 

0.2 

3 

20.5 

0.1 

4 

20.4 

0.5 

Calculez  la  moyenne  globale  et  l'écart-type  global. 

Solution: 

Nous  avons  démontré  dans  le  chapitre  de  Statistiques  que: 


/ 

Nÿi,tf)  =  N 

\ 


Z* 

i= 1 


il  vient  alors  immédiatement: 


M  = 


20.5  +  20.6  +  20.5  +  20.4 
4 


20.50 


et: 


(T  =  —  Vo.32  +0.22  +0.12  +0.52  =  0.156 

4 


12.3.20  Intervalle  de  confiance  de  la  moyenne  (test  Z  à  1 
échantillon) 

Enoncé: 

Un  gestionnaire  d'une  société  de  location  de  voitures  souhaiterait  estimer  le  nombre  moyen 
d'anomalies  qualité  par  mois.  Il  prend  pour  cela  un  échantillon  aléatoire  de  19  employés  et 
obtient  la  suite  suivante  de  nombre  d'anomalies  déclenchées: 
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3,7,12,5,9,13,2,8,6,14,6,1,2,3,2,5,11,13,5 
El.  Calculez  la  moyenne  arithmétique 
E2.  Déterminez  l'intervalle  à  95%  de  la  moyenne 

Solution: 

51.  La  moyenne  arithmétique  vaut: 

-  _  3+7+12+5+9+13+2+8+6+14+6+1+2+3+2+5+11+13+5 

A  —  - 

19 

52.  Nous  avons  démontré  que: 

x  - 4=4/2 («- 1)  <  n  <  X  + -?=Tal2 (n  - 1) 
yn  yn 


avec: 


S2 


1 


n- 1 


n  O 

E(x,-x)2 


Nous  avons  alors: 

-  3+7+12+5+9+13+2+8+6+14+6+1+2+3+2+5+11+13+5 

X  — - —  0.68 

19 

5  =  ECARTYPE(3;7;12;5;9;13;2;8;6;14;6;1;2;3;2;5;11;13;5)=4.23 
n  =  19 

df=n- 1  =  18 

^0.025  (18)=LOISTUDENrr.INVERSE(5%;  18)  =  2.1 
Nous  calculons: 


6.68 


4  23 

— 5=2.1  <  //  <  6.68  + 
V19 


4.23 

VÏ9 


2.1 


Soit  95%  de  probabilité  cumulée  que  la  moyenne  se  trouve  dans  l'intervalle: 

4.64  <  ju<  8.71 


12.3.21  Intervalle  de  confiance  de  la  proportion 

Enoncé: 
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Dans  une  production  de  300  pièces,  nous  en  avons  trouvé  8  de  défectueuses.  Quel  est 
l'intervalle  de  confiance  à  95%  de  la  proportion  de  pièces  défectueuses? 

Solution: 

Avec  a  =  5% ,  nous  avons  alors: 


p-z0.. 


025- 


n 


<p<p  +  ZQ: 


025- 


p-a-P) 


n 


p  -1.96 


p-a-p) 


<  p  <  p  +  1.96 


p-a-p) 


V  n  v  n 

Nous  avons  d'une  production  de  300  éléments  trouvés  8  qui  étaient  défectueux.  Nous 
vérifions  d'abord  avec: 


8 

300 


2.66% 


que: 


O 

n-  p  =  300 - =  8  >  5 

300 

Donc  il  est  acceptable  d'utiliser  l'intervalle  de  confiance  par  la  loi  Normale.  Nous  avons  dès 
lors: 


8 

( 

8  1 

8  1  961 

300 

1- 

V 

300  J 

300  \ 

300 

<  p< 


300 


■  +  1.96< 


8 

( 

8  1 

1- 

300 

V 

300  J 

300 

0.84%  <  p  <  4.49% 


12.3.22  Intervalle  de  confiance  de  l’écart-type 

Enoncé: 

Un  échantillon  de  9  vis  a  été  tiré  d'une  ligne  de  production  et  la  mesure  de  leur  diamètre  en 
[mm]  a  été  reportée  ci-dessous: 

13,13,12,12.55,12.99,12.89,12.88,12.97,12.99 

El.  Calculez  l'écart- type 

E2.  Estimez  l'intervalle  de  confiance  de  l'écart-type  à  95%. 

Solution: 

SI.  L'écart-type  vaut  (à  mettre  dans  MS  Excel): 
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=ECARTTYPE(13;13;12;12.55;12.99;12.89;12.88;12.97;12.99)=0.335 


S2.  Nous  avons  démontré  que: 


(n-l)S2  ^  2  (n-l)S2 

- S  CF  s - 

Xal2^n~^)  Xl-a/2^n  _1) 


avec: 


Nous  avons  alors: 


S2  =  ECARTYPE(13;13;12;12.55;12.99;12.89;12.88;12.97;12.99)A2=0.112 
n  =  9 

df  =  n- 1  =  8 

Jo2o25(8)=khiDEUx.iNVErsE(0.025;8)=17.534 
Xo.9i5  (8)=KHIDEUX.INVERSE(0.97 5  ;  8)=2. 179 


Donc: 


8-0.112 

2.179 


17.534 


soit: 


0.051  <<72  <0.412 

Soit  95%  de  probabilité  cumulée  que  l'écart-type  se  trouve  dans  l'intervalle: 

0.226  <  cr  <  0.642 

12.3.23  Nombre  d'échantillons  pour  une  mesure 

Enoncé: 

Un  gestionnaire  responsable  d'une  chaîne  de  production  veut  savoir  combien  de  temps  passe 
en  moyenne  un  employé  à  l'usinage  sur  une  pièce  donnée.  Celui-ci  aimerait  être  dans  une 
estimation  se  trouvant  dans  les  ±2  minutes  par  rapport  à  la  moyenne  et  il  est  connu  que 
l'écart-type  d'usinage  est  de  3  minutes. 

Quelle  taille  d'échantillon  de  mesures  doit-il  prendre  pour  s'assurer  un  intervalle  de  confiance 
à  95%  de  la  moyenne  qu'il  mesurera? 
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Solution: 


Nous  prenons  la  relation  démontrée  dans  le  cours  de  statistiques: 


n  = 


Z2cr 2 


LOI.NORMALE.STANDARD.INVERSE((l-95%)/2)  •  3Ÿ 


8.64 


12.3.24  Nombre  d’échantillons  pour  une  proportion 

Enoncé: 

Nous  souhaiterions  savoir  le  nombre  d'échantillons  à  prendre  d'un  lot  de  production  sachant 
que  la  proportion  de  défectueux  est  imposée  à  30%  avec  une  erreur  tolérée  d'environ  5%  entre 
la  proportion  réelle  et  empirique  et  ce  afin  d'obtenir  un  intervalle  de  confiance  à  un  niveau  de 
95%  du  résultat: 

Solution: 

Nous  prenons  la  relation  démontrée  dans  le  cours  de  statistiques: 

Zap(\-p )  Z5%  30%(1  -  30%)  1.96 -30% -70% 

n  = - - - = - - - = - - - =  165 

S2  5%2  5%2 


12.3.25  Comparaison  de  deux  proportions 

Enoncé: 

Dans  le  cadre  d'un  plan  d'échantillonnage  nous  avons  prélevé  sur  un  premier  lot  de  50 
échantillons,  48  en  parfait  états.  Dans  un  second  lot  de  30  échantillons,  26  étaient  en  bon  état. 

Nous  avons  donc: 


px  =  —  =  96%,  pY  =  —  =  86.66% 

x  50  Y  30 

Nous  souhaiterions  donc  savoir  si  la  différence  est  significative  avec  une  certitude  de  95%  ou 
simplement  due  au  hasard? 

Solution: 

Nous  utilisons  alors: 


P_nlpl+n2p2 
nx  +  n2 


48  +  26 
50  +  30 


92.50% 


et: 
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fi  n 
0.925  -(1  -0.925)  — +  — 
A  50  30 J 


0.96-0.8666 


Vincent  ISOZ 


Ce  qui  correspond  à  une  probabilité  cumulée  en  utilisant  MS  Excel  de: 


=NORMSDIST(1.545)=93.88% 


Donc  la  différence  est  dû  au  hasard  (ceci  dit  c'est  presque  in  extremis. . .). 


12.3.26  Test  d'hypothèse  t-student  bilatéral 


Enoncé: 


Une  machine  utilisée  pour  produire  des  joints  a  été  stable  et  opérante  sous  contrôle  statistique 
pendant  plusieurs  années.  Mais  récemment,  l'épaisseur  des  joints  semble  être  plus  petite  qu'ils 
ne  l'étaient  au  préalable. 

L'épaisseur  moyenne  était  historiquement  de  //  =  0.070 .  Un  responsable  qualité  (AQ:  Quality 
Assurance)  veut  déterminer  si  l'âge  des  machines  est  la  cause  de  cette  variation.  Pour  cela,  il 
prend  un  échantillon  de  10  joints  pour  le  test  et  trouve  une  moyenne  arithmétique  de 
l'échantillon  de  0.074.  et  un  écart-type  sans  biais  de  0.008. 

Nous  souhaiterions  tester  l'hypothèse  comme  quoi  la  machine  fonctionne  correctement  avec 
un  intervalle  de  confiance  de  95%  ! 


Solution: 


Comme  nous  ne  connaissons  pas  la  variance  théorique,  nous  devons  utiliser  le  test-r. 
Nous  avons  donc: 


avec  les  données  suivantes: 


X  =  0.074 
s  =  0.008 

ti  =  10 

df  =  n- 1  =  9 

7(3.025  (9)=LOI.STUDENT.INVERSE(2.5%;9)=2.69 


Soit: 
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0.074  -  2.69  ^22  <ju<  0.074  +  2.69  °'008 


VÔ) 


Ce  qui  donne: 


0.0595  <//<  0.142 

Comme  la  moyenne  historique  se  trouve  dans  l'intervalle  de  confiance,  il  s'ensuit  que  nous 
devons  rejeter  l'hypothèse  comme  quoi  la  variation  est  due  au  vieillissement  de  la  machine. 


12.3.27  Méthode  ABC  avec  courbe  de  Lorenz 

Enoncé: 

Soit  les  données  suivantes: 


A 

B 

c 

1 

N°  Machine 

Arrêt  [h.]  Nb.  de  pannes 

2 

1 

100 

4 

3 

2 

32 

5 

4 

3 

50 

4 

5 

4 

19 

2 

6 

5 

4 

3 

7 

6 

30 

4 

8 

7 

40 

12 

9 

8 

80 

15 

10 

9 

55 

8 

11 

10 

150 

8 

12 

11 

160 

14 

13 

12 

5 

8 

14 

13 

10 

3 

15 

14 

20 

3 

Déterminez  les  machines  engendrant  80%  des  coûts  horaires  cumulés  par  rapport  au  cumul 
des  pannes. 

Solution: 

Dans  MS  Excel  ou  ailleurs  nous  devons  d'abord  (aisément)  établir  le  tableau  suivant: 
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avec  les  relations  suivantes: 


A 

B 

c 

D 

E 

1  F 

1 

N°  Machine 

Arrêt  [h.] 

Cumul  coûts  [h.] 

%  Cumulé 

Nb.  de  pannes 

Cumul  pannes 

2 

11 

160 

=B2 

=C2/$C$15 

4 

=E2 

3 

10 

150 

=B3+C2 

=C3/$C$15 

5 

=F2+E3 

4 

1 

100 

=B4+C3 

=C4/$C$15 

4 

=F3+E4 

5 

8 

80 

=B5+C4 

=C5/ÏCÏ15 

2 

=F4+E5 

6 

9 

55 

=B6+C5 

=C6/$C$15 

3 

=F5+E6 

7 

3 

50 

=B7+C6 

=C7/ÏCÏ15 

4 

=F6+E7 

8 

7 

40 

=B8+C7 

=C8/ÏCÏ15 

12 

=F7+E8 

9 

2 

32 

=B9+C8 

=C9/$C$15 

15 

=F3+E9 

10 

6 

30 

=B10+C9 

=C10/$C$15 

8 

=F9+E10 

11 

14 

20 

=B11+C10 

=cii/œcœis 

8 

=F10+E11 

12 

4 

19 

=B 1 2+C 1 1 

=C12/$C$15 

14 

=F1 1 +E12 

13 

13 

10 

=B 1 3+C 1 2 

=C13/$C$15 

8 

=F12+E13 

14 

12 

5 

=B14+C13 

=C14/$C$15 

3 

=F13+E14 

15 

5 

4 

=B15+C14 

=C15/$C$15 

3 

=F14+E15 

Nous  avons  alors  graphiquement: 
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%Cumulé  pannes 

où  les  zones  A,  B  et  C  sont  arrondis  à  des  points  existants.  Ainsi,  la  zone  critique  A  compte  les 
machines  11,  10,  1,  8,  9  et  3.  Une  amélioration  de  la  fiabilité  de  ces  machines  peut  donc 
procurer  jusqu'à  78.8%  du  temps  total  cumulé  sur  les  pannes. 


12.3.28  SPC  de  projets 

Enoncé: 

Les  déviations  temporelles  en  %  de  25  tâches  donnent  les  valeurs  suivantes  après  clôture  d'un 
projet: 


A  B 

Ecarts  Ecarts 

45% 

15% 

40% 

15% 

35% 

15% 

35% 

10% 

30% 

10% 

30% 

10% 

25% 

5% 

25% 

5% 

25% 

0% 

20% 

-5% 

20% 

-5% 

20% 

-10% 

20% 

El.  Nous  aimerions  savoir  si  les  estimations  du  responsable  de  projet  sont  sous  contrôle  (test 
de  normalité  de  Kolmogorov-Smimov  sous  Minitab). 


Ingénierie  de  Gestion  de  projets 


518/547 


E2.  Nous  souhaitons  faire  une  analyse  de  capabilité  des  déviations  en  faisant  les  calculs 
manuellement  et  en  les  vérifiant  avec  Minitab  en  prenant  l'intervalle  LSL/USL  de  [-0.1,02] 
avec  une  cible  nulle. 

Solution: 

SI.  Nous  ouvrons  Minitab  et  reportons  les  données  dans  une  unique  colonne: 


^Minitab  -  Sans  titre 


JjSjx] 


Fichier  Edition  Données  Cale  Stat  Graphique  Editeur  Outils  Fenêtre  Aide 


a;  u  s  *  ««ut  *  «fi  s> 


im  y  y  \a 


ii2  K  ElU 


*  y  +  p 2 ir 


~3  I  x  I Q.  I  *  T  1=1  o  \  »  u  td 


|  EUT  Session 

17.02.2010  20:36:2; 

ns  ïïini  tab  ,  appuyé 

3 

I 

J 

A 

Bienvenue  da 

Lu 

:z  sur  Fl  pour  obtenir  de  l'aide. 

|f!jjjj  Feuille  de  travail  I  *** 

4r 

Cl 

C2 

C3 

a 

C5 

C6 

C7 

C8 

C9 

CIO 

Cil 

C12 

C13 

ci-U 

Ecarts 

□ 

1 

45.00% 

40.00% 

35.00% 

35.00% 

30.00% 

30.00% 

25.00% 

2 

3 

4 

| 

5 

6 

7 

H 

liL- 

AA 

hblJWffllgl  fllnl  x|| 


Feuille  de  travail  en  cours  :  Feuille  de  travail  1 


Nous  allons  dans  le  menu  Stat/Statistiques  élémentaires/Test  de  normalité...: 


Ingénierie  de  Gestion  de  projets 


519/547 


Vincent  ISOZ 


Tester  si  les  données  suivent  une  loi  normale 

Nous  remplissons  la  boîte  de  dialogue: 


^>jMinitab  -  Sans  titre 


JjS|x] 


Fichier  Edition  Données  Cale  Stat  Graphique  Editeur  Outils  Fenêtre  Aide 


gSD'A  j  MAIS  f  m  j€iitDI 


f*  “I  “1  min  flï  \& 


Us'l  m+psT 


73 1  x  1 0.  J  *  T  1=1  o  \  »  u  ü 


^isi*i 


17.02.2010  20:36:23 


Test  de  normalité 


Bienvenue  dans  ïïinitab,  appuyés 


Feuille  de  travail  1 


Cl 


Ecarts 


C2 


45.00% 

40.00% 

35.00% 

35.00% 

30.00% 

30.00% 

25.00% 


C3 


Aide 


Ht  fllnl  X|| 


2SJ 


Variable  :  f  Ecarts 

Lignes  des  percentiles 
f*  Aucune 

C  Aux  valeurs  V  :  J- 
C  Aux  valeurs  :  | 

Tests  de  normalité 
C  Anderson-Darling 

C  Ryan-Joiner  (semblable  à  Shapiro-Wilk) 
<*  Kolmogorov-Smirnov 


Sélectionner  |  Titre  :  |  Ecarts  Projets 


Annuler 


Cil 


C12 


C13 


^Jn]x] 

"^3 


Tester  si  les  données  suivent  une  loi  normale 


et  validons  par  OK  ce  qui  donne: 
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La  p-value  étant  supérieur  à  0.05  (puisque  Minitab  indique  qu'elle  est  plus  grande  que  0.150) 
fait  qu'on  peut  accepter  sans  crainte  l'hypothèse  de  normalité. 

S2.  Nous  faisons  d'abord  les  calculs  à  la  main: 


C, 


USL-LSL 

6(7 


0.1 -(-0.2) 
6-0.143 


=  0.35 


ce  qui  est  très  médiocre! 

Remarque:  Cette  valeur  correspond  à  la  capabilité  long  terme  Pp  dans  Minitab. 

Nous  avons  pour  la  capabilité  potentielle  décentrée: 

r  \ 


Cpk  =  cp{\-k)  =  cp 


\T-m\ 


-(USL-LSL) 

2  J 


□  0.35 


r 


v 


|-0.05-0.174| 
0.5(0.1  -  (-0.2)) 


=  0.35 


0.224 

0.15 


=  -0.172 


où  pour  rappel: 


t_usl+lsl 
~  2 

Donc  comme  k  est  supérieur  à  1  (et  donc  Cpu  inférieur  à  0),  nous  sommes  au-delà  de  USL  (ce 
que  nous  confirmera  la  graphique  Minitab). 

Remarque:  Cette  valeur  correspond  à  la  capabilité  potentielle  long  terme  Ppk  dans  Minitab. 
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Dans  Minitab  nous  allons  dans  Outils  de  la  qualité/ Analyse  de  capabilité/Normale. . .  : 


Analyser  les  données  qui  suivent  une  loi  normale 


Nous  paramétrons  l'analyse  de  capabilité: 


nous  cliquons  sur  le  bouton  Options. . .  et  complétons  la  boîte  de  dialogue: 
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Analyse  de  capabilité  (loi  normale)  -  Options 


Cible  (ajoute  Cprm  au  tableau)  :  |o 

Utiliser  la  tolérance  de  K*sigma  pour  les  statistiques  de  capabilité  K  =  [T 

Exécution  de  l'analyse  Affichage 

Analyse  à  l'intérieur  des  sous-groupes  C  Parties  par  million 
|“  Analyse  globale  <*  Pourcentages 


(*  Statistiques  de  capabilité  (Cpj  Pp) 
C  Z  de  référence  (niveau  de  sigma) 


I-  Inclure  les  intervalles  de  confiance 

Niveau  de  confiance  :  | 

Intervalles  de  confiance  : 


Bilatéral 


Titre  : 


Aide 

OK 

Annuler 

Graphiquement  nous  avons  finalement: 
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Vincent  ISOZ 


13.  Glossaire 

Acceptation 

Acte  par  lequel  le  signataire  considère  que  les  travaux  ou  les  services  qui  lui  sont  soumis  lui 
conviennent  (Selon  AFNOR  1996) 

Attente 

C'est  une  opinion  ou  une  demande  de  satisfaction  des  besoins  des  clients.  (Selon  AFNOR  2004) 

Attitude 

Pensée,  état  d'esprit  d'une  personne  ou  d'un  groupe,  tels  que  peuvent  les  révéler  les  différentes  formes 
de  recueil  d'opinions.  L'attitude  est  en  général  un  ensemble  d'opinions  relativement  stables  laissant 
prévoir  un  certain  comportement  vis-à-vis  d'un  problème  ou  d'un  sujet  donné.  (Selon  AFNOR  2004) 

Attractivité 

Mesure  d'attirance  de  la  population  environnante  d'un  point  de  vente.  Plus  la  clientèle  vient  de  loin, 
plus  le  coefficient  d'attractivité  est  important.  Cette  attractivité  peut  être  augmentée  par  les  différents 
éléments  de  l'offre  de  service  du  point  de  vente  (gamme  de  produits  ou  de  service  élargie,  prix 
intéressant,  communication  et  publicité,  horaire  d'ouverture,  taille  du  magasin. . .)  La  qualité  de 
l'accueil  (amabilité  du  personnel,  disponibilité,  compétence. . .)  peut  être  un  élément  important 
d'attractivité  d'un  point  de  vente.  (Selon  AFNOR  2004) 

AMDEC 

Signifie:  Analyse  des  Modes  de  Défaillance,  de  leurs  Effets  et  de  leurs  Criticités)  Méthode  de 
prévention  quantitative  d'analyse  de  fiabilité. 

Approbation 

Acte  par  lequel  le  signataire  atteste  que  les  travaux  ou  services  qui  lui  sont  soumis  ont  été  exécutés 
conformément  à  ses  demandes.  (Selon  AFNOR  1996) 

Autorisation 

Acte  par  lequel  un  signataire  qualifié  certifie  qu'il  ne  s'oppose  pas  au  démarrage  d'une  tâche.  (Selon 
AFNOR  1996) 

Baromètre 

Echelle  de  mesure  des  opinions  et  des  attitudes  des  clients  et  non  clients  d'un  point  de  vente,  d'une 
marque,  d'un  produit.  L'étude  est  faite  régulièrement  pour  mesurer  les  évolutions  d'une  période  à 
l'autre.  L'utilisation  d'un  baromètre  est  utile  pour  mesurer  les  effets  des  actions  d'une  entreprise  sur 
l'opinion  de  ses  clients.  (Selon  AFNOR  2004) 

Benchmarking 

Recherche  des  méthodes  les  plus  performantes  pour  une  activité  donnée,  permettant  de  s'assurer  une 
supériorité  par  rapport  à  la  concurrence.  Cette  méthode  consiste  à  comparer  les  méthodes  et  les  savoir- 
faire  de  l'entreprise  avec  ceux  des  entreprises  considérées  comme  les  plus  performantes,  à  analyser  les 
écarts  de  performance  et  à  rechercher  à  transposer  les  meilleures  pratiques  dans  l'entreprise.  Il  est 
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également  possible  de  faire  du  benchmarking  interne  en  comparant  les  résultats  et  les  méthodes  de 
différentes  agences.  (Selon  AFNOR  2004) 

Brainstorming  -  Technique  utilisée  dans  certaines  réunions  consistant  à  lister  toutes  les  idées  sur  une 
problématique,  ensuite  de  structurer  celles-ci  et  de  ne  garder  que  celles  étant  réalistes  par  itération. 

Budget  encouru 

Expression  abrégée  pour  désigner  le  Coût  budgété  du  travail  prévu  (CBTP)  [Anglais:  Budgeted  Cost 
of  Work  Scheduled  (BCWS).]  Part  du  budget  à  date  correspondant  aux  travaux  qui  auraient  dû  être 
réalisés  à  la  date  considérée,  si  on  avait  travaillé  en  conformité  avec  les  programmes  et  budget 
initiaux.  (Selon  AFNOR  1996) 

Budget  initial  de  projet 

Objectif,  en  matière  aussi  bien  de  recettes  que  de  coûts,  pour  l'ensemble  du  projet,  et  ce  jusqu'à  sa 
réception  définitive.  (Selon  AFNOR  1996) 

Bureau  de  projet 

Entité  organisationnelle,  composé  d'une  ou  plusieurs  personnes,  agissant  comme  un  centre  de 
connaissance,  de  coordination  et  de  contrôle.  (Selon  Lalonde  2008) 

Cahier  de  charges  (CdC) 

Document  rassemblant  les  obligations  et  les  éléments  nécessaires  pour  définir  un  besoin  (traitement 
d'informations,  méthodes  et  outils  de  travail,  etc.)  et  les  principales  contraintes  à  respecter  pour  le 
satisfaire.  Le  client  choisit  usuellement  son  fournisseur  sur  la  base  d'un  cahier  des  charges.  Faute  d'un 
document  normalisé,  on  emploie  divers  documents  tels  que:  note  de  principe,  objectifs,  plan-guide, 
schéma  directeur,  ou  simplement  des  notes  internes,  fiches  descriptives,  programmes  de  travail.  (Selon 
AFNOR  1996) 

CAPA 

Acronyme  anglophone  pour:  Corrective  actions  (actions  correctives)/Preventive  actions 
(actions  préventives) 

Capital  client 

Les  clients  d'une  entreprise  représentent  un  «  Capital  »  dont  la  valeur  peut  s'apprécier  suivant  leur 
nombre,  leurs  caractéristiques,  le  chiffre  d'affaires  actuel,  le  chiffre  d'affaires  potentiel.  (Selon  AFNOR 
2004) 

Carte  des  forces 

Cartographie  des  acteurs  concernés  par  le  projet 

CBTE 

voir  Coût  budgété  du  travail  effectué  (BCWP)  (Selon  AFNOR  1996) 

CBTP 

voir  Budget  encouru  (Selon  AFNOR  1996) 

Certification 
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Acte  par  lequel  une  personne  physique  ou  morale  (le  certificateur)  reconnaît  qu'une  autre  (le  certifié)  a 
satisfait  à  un  certain  nombre  de  critères  définis.  (Selon  AFNOR  1996) 

Change  request 

Proposition  de  modification  d'un  Configuration  Item  (CI).  Fait  généralement  suite  à  une  erreur  connue 
ou  à  l'apparition  d'une  nouvelle  appartenance  d'un  élément  dans  l'infrastructure.  Si  une  solution 
requiert  un  changement  de  configuration  Item  CI,  la  Gestion  des  problèmes  établit  une  demande  de 
changement  à  l'intention  de  la  gestion  des  changements.  Cette  demande  est  formulée  sur  papier/écran 
ad  hoc.  La  demande  de  changement  est  clôturée  lorsque  le  changement  dans  l'infrastructure  est  réalisé 
et  validé.  Un  change  request  peut  donc  être  une  demande  d'action  corrective,  préventive  ou 
simplement  d'une  modification. 

Charte  d'équipe 

Renferme  habituellement  les  éléments  suivants:  Moyens  &  modes  de  communication,  Modes 
d'opération,  Processus  de  résolution  des  conflits,  Ensemble  de  la  documentation  à  rédiger. 

Charte  de  projet  (CdP) 

Renferme  habituellement  les  éléments  suivants:  Identification  /  Contexte  /  But  du  projet  /  Objectifs  du 
projet  /  Contenu  /  Alignement  stratégique  /  Parties  prenantes  /  Risques  /  Capacités  requises  /  Bénéfices 
potentiels  /  Ressources  humaines  requises  /  Impacts  de  ne  pas  faire  le  projet  /  Signatures  & 
Recommandation 

Chef/Responsable  de  projet 

(1)  C'est  la  personne  physique  chargée  par  le  maître  d'œuvre,  dans  le  cadre  d'une  mission  définie, 
d'assurer  la  maîtrise  du  projet,  c'est-à-dire  de  veiller  à  sa  bonne  réalisation  dans  les  objectifs  de 
technique,  de  coût  et  de  délai.  Souvent,  le  maître  d'ouvrage  identifie,  en  son  sein,  un  interlocuteur  au 
responsable  de  projet  du  maître  d'œuvre.  Cet  interlocuteur  est  aussi  appelé  responsable  de  projet. 

Dans  ce  cas,  il  y  a  lieu  de  préciser  de  quel  responsable  de  projet  on  parle.  Bien  que  l'emploi  de  cette 
expression  soit  généralisé,  beaucoup  hésitent  sur  le  «  Chef  »  et  préfèrent  «  Pilote  de  projet  »,  « 
Coordinateur  de  projet  »,  «  Responsable  de  projet  ».  À  notre  avis,  si  on  ne  veut  pas  utiliser  «  Chef  de 
projet  »,  la  meilleure  autre  appellation  reste  «  Responsable  de  projet  ».  (Selon  AFNOR  1996) 

(2)  Personne,  désignée  par  l'entreprise  réalisatrice,  qui  est  chargé  d'atteindre  les  objectifs  du  projet. 

Elle  peut  dépendre  hiérarchiquement  d'un  responsable  de  programme,  d'un  responsable  de  portefeuille 
ou  d'un  responsable  fonctionnel  (Selon  PMBoK  2008) 

Chemin  critique  du  PERT 

Un  des  chemins  allant  de  l'étape  initiale  à  l'étape  finale  dans  un  PERT  est  appelé  le  «Chemin  critique». 
Il  correspond  à  la  durée  minimale  de  réalisation  du  projet.  Tout  retard  sur  l'une  des  tâches  sur  ce 
chemin  critique  (correspondant  à  la  durée  minimale  du  projet)  allonge  donc  la  durée  totale  du  projet. 

Cible 

(1)  Ensemble  des  clients  potentiels  qu'une  entreprise  a  décidé  d'atteindre  au  moyen  d'une  action  de 
promotion  ou  d'un  plan  de  communication  spécifique  (ne  pas  confondre  avec  segment).  (Selon 
AFNOR  2004) 

(2)  Dans  un  Contrat,  le  client  est  celle  des  deux  parties  qui  reçoit  un  ouvrage,  un  objet  ou  une 
prestation  qu'elle  doit  payer  aux  conditions  convenues.  (Selon  AFNOR  1996)  Personne  ou  organisation 
qui  utiliseront  le  produit,  le  service,  ou  le  résultat  du  projet  (Selon  PMBoK  2008) 
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Colloque 


Réunion  de  spécialistes  invités,  en  nombre  généralement  limité,  pour  exposer,  discuter  et  confronter 
leurs  idées  et  leurs  opinions  sur  un  thème  donné.  Quasi-synonyme(s):  Conférence.  Terme(s)  à  éviter: 
Séminaire  /  Symposium  (Selon:  OQLF) 

Commanditaire 

Personne  ou  groupe  qui  finance  le  projet,  en  capitaux  ou  en  nature  (Selon  PMBoK  2008) 

Communication  sur  le  lieu  de  vente  (CLV) 

Ensemble  des  manifestations  publicitaires  d'un  produit  ou  d'une  marque  sur  le  lieu  de  vente.  Les 
matériels  de  publicité  sur  le  lieu  de  vente  sont  chargés  de  mettre  le  produit  en  valeur  soit  seul,  soit  en 
association  avec  des  campagnes  de  publicité  (affichage,  télévision,  radio...)  (Selon  AFNOR  2004) 

Congrès 

Assemblée  regroupant  un  nombre  important  de  personnes  réunies  pour  délibérer  sur  un  ou  des  sujets 
donnés. 

Contrat 

Convention  par  laquelle  une  ou  plusieurs  personnes  s'obligent  envers  une  ou  plusieurs  autres,  à 
donner,  à  faire  ou  à  ne  pas  faire  quelque  chose.  (Selon  AFNOR  1996) 

Contraintes  concurrentes 

Contraintes  devant  être  pondérées  par  le  chargé  de  projet  en  vue  d'une  solution  optimale,  touchant 
notamment  au:  Contenu  /  Qualité  /  Échéancier  /  Budget  /  Ressources  et  compétences  requises  / 
Risques  (Selon  PMBoK  2008) 

Coordination 

Activité,  fonction  et  ensemble  d'actions  dont  l'objet  est  de  faciliter  les  interactions  entre  activités 
concourant  à  un  même  objectif.  La  planification  permet  de  résoudre  potentiellement  des  problèmes  de 
coordination  mais  ne  fait  pas  partie  de  l'activité  de  coordination.  Il  est  possible  de  coordonner  des 
activités  qui  n'ont  pas  été  planifiées  et/ou  sont  non  planifiables.  La  coordination  comprend  les  tâches 
suivantes:  -La  définition  sous  forme  de  prescriptions,  de  directives  et  recommandation  de  règles  et 
conditions  à  remplir  pour  que  les  actions  soient  rendues  a  priori  cohérentes;  -La  communication,  la 
mise  en  application  et  la  vérification  et  l'application  des  prescriptions,  de  directives  et 
recommandations  de  règles  et  conditions  auprès  de  et  par  les  intervenants  concernés;  -L'application 
pratique  de  règles  permettant  l'établissement  d'informations  dont  la  communication  permettra  aux 
intervenants  responsables  des  activités  de  se  coordonner;  -La  vérification  que  les  interactions  entre 
tâches  se  sont  déroulées  correctement  et  la  prise  de  décisions  correctives  si  tel  n'est  pas  le  cas;  -La 
conception,  la  mise  en  place  et  l'exploitation  des  moyens  nécessaires  et  utiles  aux  actions  de 
coordination  et  à  l'échange  naturel  d'informations  entre  les  intervenants  devant  coopérer.  (Selon 
AFNOR  1996) 

Courbe  des  engagements 

Courbe  des  engagements  financiers  dans  un  programme  (ou  un  projet)  caractérisée  par  une  très  forte 
croissance  sur  une  courte  période,  soit  le  temps  de  prise  de  décision  (Selon  Aim  2007) 

Courbes  en  S 
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Les  dépenses  d'un  projet  ont,  sur  la  durée  du  cycle  de  vie  du  projet,  une  allure  caractéristique  montrant 
3  phases:  Démarrage  /  Croissance  /  Décélération  (Selon  Aim  2007) 

Coût 

Charge  (ou  dépense)  supportée  par  un  intervenant  économique  par  la  suite  de  la  production  ou  de 
l'utilisation  d'un  produit  (NF  X50-150,  cité  par  Aim2007) 

Coût  budgété  du  travail  effectué  (CBTE) 

C'est  la  valorisation  à  coût  budget  du  travail  réalisé  à  une  date  donnée.  Généralement,  le  CBTE  est 
obtenu  en  multipliant  la  valeur  du  budget  à  date  par  l'avancement  physique.  (Selon  AFNOR  1996) 

Coût  budgété  du  travail  prévu  (CBTP) 

Voir  Budget  encouru  (Selon  AFNOR  1996) 

Coût  encouru 

Les  coûts  encourus  sur  un  projet  à  un  moment  donné  correspondent  au  coût  réel  des  prestations 
réellement  effectuées  à  cette  date  et  qui  sont  imputables  au  projet.  L'objectif  poursuivi  par  la  mesure 
périodique  du  coût  encouru  est  de  permettre  de  suivre  d'une  part  l'évolution  des  coûts  internes  et 
d'autre  part,  l'écart  de  coût  des  éléments  sous-traités  du  projet.  (Selon  AFNOR  1996) 

Coût  prévisionnel 

Par  définition,  le  coût  prévisionnel  est,  à  un  instant  donné,  le  meilleur  pronostic  possible  de  ce  que 
coûtera  l'élément  considéré  à  la  fin  du  projet.  Comme  le  budget,  le  coût  prévisionnel  est  établi,  ligne 
par  ligne,  suivant  le  même  découpage  et  peut  être  exprimé  dans  diverses  bases  économiques  (les 
comparaisons  devant  toujours  être  effectuées  sur  des  bases  identiques).  Les  coûts  prévisionnels  sont 
exprimés  dans  la  même  monnaie  que  les  recettes  contractuelles  correspondantes.  L'estimation  du  coût 
prévisionnel  des  lignes  budgétaires  est  faite  en  tenant  compte  du  caractère  propre  à  chacun  des  trois 
types  de  coûts  (ingénierie,  matériel,  travaux),  et  de  l'état  d'avancement  du  projet,  soit:  -Coûts  encourus 
plus  coûts  restant  à  encourir;  -Coûts  engagés  (voir  engagement),  plus  coûts  restant  à  engager;  - 
Dépensé,  plus  reste  à  dépenser.  (Selon  AFNOR  1996) 

Coûtenance 

Processus  permettant,  pendant  toute  la  durée  d'un  projet,  de  prévoir  et  suivre  tous  les  coûts  des 
activités  successives  pour  la  réalisation  de  l'ouvrage  avec  l'objectif  de  maîtriser  un  coût  prévisionnel 
final.  Ce  processus  s'appuie  sur  une  démarche  prévisionnelle  permanente.  Au  lancement  du  projet,  est 
établi  le  budget  initial  résultant  de  l'économie  générale  du  prix  de  vente.  Indépendamment  des 
objectifs  de  coût  et  de  recette  qu'on  fixe  à  la  direction  de  projet,  la  coûtenance  aura  pour  mission 
durant  la  vie  du  projet,  de  calculer  l'évolution  prévisionnelle  de  chaque  élément  des  lignes  budgétaires 
correspondant  aux  besoins.  (Selon  AFNOR  1996) 

Coûts  directs  /  indirects 

Répartition  des  coûts  selon  qu'ils  sont  affectables  directement  ou  par  répartition  dans  la  décomposition 
choisie  pour  le  suivi  budgétaire.  Cette  notion  peut  s'appliquer  à  diverses  structures  de  coûts.  Par 
exemple,  si  l'on  considère  l'affectation  au  matériel,  sont  considérés  comme: 

(1)  Coûts  directs:  Chacun  des  coûts  correspondent  à  la  fourniture  des  équipements  principaux  et  des 
matériels  banalisés  [  sortie  usine  (ex-works),  ou  Franco  à  bord  (FOB)  ],  et  aux  travaux  de  construction 
des  installations  définitives.  Les  transports  des  équipements  et  matériels  font  normalement  partie  des 
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coûts  directs  ;  en  estimation,  toutefois,  ils  sont  en  général  calculés  globalement  et  regroupés  avec  les 
coûts  indirects. 

(2)  Coûts  indirects:  Somme  de  tous  les  coûts  liés  à  la  réalisation  du  contrat  mais  qui  ne  peuvent 
s'imputer  à  un  élément  précis  de  l'ouvrage  (étude,  supervision,  assurance  de  la  qualité,  coûts  indirects 
de  travaux,  etc.)  Les  coûts  généraux  indirects  tels  que  l'ingénierie  (étude  au  siège  et  supervision  du 
site),  direction  de  projet,  études  initiales  et  reconnaissance  du  site,  services  divers  (certification,  etc.) 
assurances,  . . .,  sont  souvent  du  ressort  du  maître  d'œuvre  alors  que  l'acquisition  et  la  préparation  du 
site,  la  mise  à  disposition  des  entreprises,  les  droits  de  passage,  les  licences,  sont  en  général  à  la  charge 
du  maître  d'ouvrage.  Pour  les  coûts  d'ingénierie,  ou  plus  généralement  les  coûts  de  main-d'œuvre,  sont 
considérés  comme  coûts  directs  ceux  liés  directement  aux  salaires  versés,  et  comme  indirects  les  coûts 
d'encadrement  (Selon  AFNOR  1996) 

CPM 

Critical  Path  Method  (Selon  AFNOR  1996) 

Créativité 

Capacité  à  découvrir  de  nouvelles  solutions  à  un  problème.  Elle  s'exerce  en  posant  les  problèmes  de 
façon  nouvelle  et  en  combinant  de  façon  originale  des  idées  pour  inventer  de  nouvelles  solutions. 
(Selon  AFNOR  2004) 

CRTE 

voir  Coût  encouru  (Selon  AFNOR  1996) 

Cycle  de  vie  du  projet 

Organisation  logique  des  activités  qui  jalonnent  la  vie  d'un  produit  depuis  l'idée  que  l'on  a  eu  ou 
l'identification  du  besoin,  jusqu'à  l'obsolescence  ou  son  arrêt  d'utilisation. 

Cycle  de  développement  d'une  équipe 

5  grandes  étapes  du  développement  typique  d'une  équipe:  Constitution  /  Tumulte  (gestion  des  tensions, 
alignement  des  objectifs,  détermination  des  rôles  et  responsabilités )  /  Cohésion  (atteinte  de  consensus 
sur  les  façons  de  procéder,  collaboration  ensemble)  /  Performance  /  Dissolution  (Selon  Tuckman,  cité 
par  Lalonde  2008) 

Défaillance 

Altération  ou  cessation  d'un  bien  à  accomplir  ou  remplir  une  fonction  requise  (NF  X60-010) 

Dépassement 

Ecart  entre  les  dépenses  et  la  valeur  budgétée  d'une  même  ligne  budgétaire.  (Selon  AFNOR  1996) 

Dérive 

C'est  la  différence  entre  les  écarts  prévus  apparaissant  sur  deux  Éditions  successives  du  rapport  de 
coût:  positive  et  négative,  elle  indique  l'efficacité  des  mesures  correctives  adoptées  (dont  l'effet  est 
rarement  immédiat).  (Selon  AFNOR  1996) 

Devis 
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Nomenclature  chiffrée  des  tâches  et  des  prestations  à  exécuter,  des  documents  à  fournir,  des  achats  à 
effectuer,  établie  à  partir  des  informations  contenues  dans  la  demande  de  devis ,  chaque  ligne 
(ingénierie,  matériels,  travaux)  étant  estimée  en  unités  d'œuvre  et  en  montant  d'achats.  (Selon  AFNOR 
1996) 

Disponibilité 

Aptitude  d'un  produit  à  être  en  état  d'accomplir  une  fonction  requise  à  un  instant  donné,  dans  des 
conditions  données,  pour  un  intervalle  donné  (NF  X50-410,  cité  par  Aim  2007) 

Écart 

Valeur  absolue  de  la  différence  entre  deux  valeurs,  par  exemple  entre  une  valeur  de  référence  (budget 
initial,  date  jalon)  d'une  grandeur  (coût,  durée)  et  sa  valeur  prévue  ou  constatée,  à  une  date  donnée. 
(Selon  AFNOR  1996) 

Écart  de  performance,  de  coût 

Au  cours  d'une  réalisation,  lorsqu'on  fait  le  point  à  un  instant  t ,  c'est  l'écart  entre  la  valeur  prévue  au 
budget  pour  le  travail  effectivement  fait  (coût  budgété  du  travail  effectué)  et  son  coût  encouru  (coût 
réel  du  travail  effectué).  (Selon  AFNOR  1996) 

Écart  final  prévisionnel  sur  budget 

Positive  ou  négative,  c'est  la  différence  entre  le  budget  à  date  et  le  coût  prévisionnel.  Il  fait  apparaître 
le  gain  ou  la  perte  par  ligne  budgétaire  et  incite  à  la  réflexion  sur  les  mesures  correctives,  sur  la  qualité 
de  l'estimation  initiale  et  sur  celle  de  la  réalisation.  En  coûtenance,  l'existence  d'un  écart  n'est  pas 
anormale,  mais  doit  être  expliquée.  (Selon  AFNOR  1996) 

Échéancier  de  paiement 

Liste  de  jalons  de  référence,  chacun  d'eux  étant  assorti  d'un  coût  ou  d'un  pourcentage  dont  le  total  est 
égal  au  montant  du  contrat  ou  de  la  commande,  qui  permet  de  prévoir  les  encaissements  et  les 
décaissements.  (Selon  AFNOR  1996) 

Encaissement 

Pour  l'entrepreneur  traitant  à  forfait,  somme  payées  par  le  maître  de  l'ouvrage  aux  dates  des  jalons 
mais  aussi  par  les  assurances,  la  COFACE,  etc.  Ils  constituent  la  partie  positive  de  la  trésorerie 
d'affaire  (cash-flow).  (Selon  AFNOR  1996) 

Engagement 

Dans  le  cadre  d'un  projet,  les  engagements  correspondent  aux  montants  que  l'entreprise  s'est  obligée, 
d'une  manière  explicite,  à  payer  à  ses  fournisseurs  en  contrepartie  d'une  fourniture.  Les  engagements 
peuvent  s'exprimer  dans  diverses  bases  économiques.  (Selon  AFNOR  1996) 

Enquête  de  satisfaction 

Catégorie  d'étude  permettant  de  recueillir  auprès  des  clients,  de  manière  rigoureuse  et  structurée,  leurs 
attentes  et  leur  niveau  de  satisfaction.  (Selon  AFNOR  2004) 

Enquête  miroir 

L'enquête  miroir  consiste  à  poser  au  personnel  de  l'entreprise  les  mêmes  questions  qu'aux  clients,  en 
leur  demandant  de  donner  les  réponses  qu'ils  pensent  que  les  clients  pourraient  donner  à  chacune  de 
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ces  questions.  La  comparaison  entre  les  résultats  de  l'enquête  miroir  et  de  l'enquête  client  permet 
d'éclairer  les  différences  de  perception  entre  l'interne  et  l'externe.  (Selon  AFNOR  2004) 

Enquête  mystère 

L'enquête  mystère  consiste  à  se  mettre  en  situation  de  clients  pour  vérifier  si  les  standards  de  service 
sont  bien  exécutés  comme  il  est  prévu  par  la  direction  (selon  les  principes  de  la  charte  accueil  si  elle  a 
été  formalisée).  Elle  est  réalisée  à  partir  d'un  scénario  prédéfini  afin  de  pouvoir  comparer  les  résultats 
sur  plusieurs  sites.  Dans  le  cas  d'une  enquête  dans  un  point  de  contact,  d'autres  éléments  tels  que 
l'aspect  du  point  de  vente,  sa  propreté,  la  clarté  de  l'affichage. . .  peuvent  compléter  l'enquête.  (Selon 
AFNOR  2004) 

Énoncé  de  réflexion  stratégique 

Couvre  l'établissement  de  la  vision,  de  l'énoncé  de  mission,  du  plan  stratégique  (ou  directeur)  et  du 
plan  annuel  d'action. 

Estimateur 

Personne  chargée  d'effectuer  l'estimation  des  coûts  d'un  projet.  (Selon  AFNOR  1996) 

Estimation 

Terme  qui  désigne  à  la  fois  une  fonction  (celle  de  l'estimateur),  une  opération  (estimer)  et  son  résultat 
(. l'estimation )  ;  en  revanche  l'anglais  utilise  trois  termes  bien  distincts. 

L'objectif  de  la  fonction  (en  anglais:  estimating)  est  d'être  à  même  de  fournir  rapidement,  à  partir  de  la 
définition  technique  succincte  d'un  programme  ou  d'un  projet  et  d'éléments  statistiques  dont  elle 
dispose,  le  coût  prévisionnel  d'une  prestation  ou  d'un  ensemble  de  prestations.  En  pratique,  les 
demandes  proviennent  de  négociateurs  commerciaux  (offres)  ou  de  responsables  d'investissement 
(études  de  faisabilité). 

L'opération  (en  anglais:  estimation)  consiste,  à  partir  de  données  insuffisantes  et  souvent  plus  ou 
moins  fausses,  à  donner  la  valeur  et  la  durée  les  plus  probables  d'une  tâche  (service  ou  fourniture), 
exécutée  par  des  tiers  sur  lesquels  on  n'a  aucune  possibilité  d'action,  à  un  moment  ultérieur  (encore) 
indéterminé.  Ces  valeurs  sont  obligatoirement  accompagnées  de  leur  degré  de  confiance  (risques  ou 
aléas  à  provisionner). 

Le  résultat  est  aussi  appelé  estimation  (en  anglais:  estimate).  En  ce  sens  on  distingue,  selon  leur  degré 
de  précision  et  le  moment  où  elles  interviennent,  l'estimation  budgétaire,  l'estimation  préliminaire,  et 
l'estimation  contractuelle  (classes  d'estimation).  On  appelle  estimation  paramétrique  une  méthode 
d 'estimation  permettant  d'obtenir  rapidement  le  prix  d'un  ouvrage  à  partir  d'une  base  de  données 
d'expériences  et  de  critères  de  dimensionnement  pertinents,  au  moyen  de  logiciels  appropriés 
(s'apparentant  à  des  systèmes  experts).  (Selon  AFNOR  1996) 

Étude  de  marché 

Etude  permettant  de  répondre  aux  questions  qu'une  entreprise  se  pose  sur  son  marché.  Elle  peut  se 
faire  en  compilant  des  études  documentaires,  des  études  qualitatives  et  des  études  quantitatives.  Dans 
le  langage  courant,  le  mot  enquête  est  surtout  utilisé  pour  un  «  recueil  d'opinions  par  questionnaire  ». 
(Selon  AFNOR  2004) 

Étude  qualitative 

Etude  ayant  généralement  pour  objet  d'analyser  les  attitudes  et  motivations  profondes  des  individus, 
des  pratiques. . .  et  qui  produit  des  résultats  non  statistiques.  L'étude  qualitative  a  souvent  une  vocation 
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exploratoire  et  se  fonde  souvent  sur  une  analyse  en  profondeur  du  discours  des  interviewés.  Portant 
sur  un  échantillon  restreint  d'individus,  qui  n'a  pas  besoin  d'être  représentatif,  elle  est  souvent  une 
phase  préliminaire  à  une  étude  quantitative.  (Selon  AFNOR  2004) 

Étude  quantitative 

Étude  ayant  pour  objet  d'analyser  les  phénomènes  mesurables  grâce  à  des  méthodes  statistiques  en 
référence  à  une  population.  Elle  est  le  plus  souvent  réalisée  par  sondage  sur  un  échantillon  qui  doit  être 
représentatif  afin  que  les  résultats  puissent  être  généralisés  à  l'ensemble  de  la  population  étudiée. 

(Selon  AFNOR  2004) 

Expérimentation 

Mise  à  l'essai  à  petite  échelle  d'un  projet  ou  d'un  plan  d'action  pour  en  mesurer  l'effet  et  pour  analyser 
les  problèmes  d'application.  (Selon  AFNOR  2004) 

Expert 

Personne  qui  a  acquis  une  grande  habilité,  par  l'expérience  et  la  pratique.  (Selon  Maders  2005) 

Facteur  clé  de  succès 

L'analyse  par  les  facteurs  clés  de  succès  permet  de  simplifier  la  réalité  de  l'organisation  lorsqu'on  est 
en  phase  d'élaboration  de  la  stratégie.  Cette  approche  suppose  que  la  réussite  d'une  organisation 
dépende  d'un  ensemble  de  facteurs  clés  (en  général,  moins  d'une  dizaine)  sur  lesquels  on  peut 
comparer  ses  performances  avec  la  concurrence.  L'avantage  de  cette  approche  est  de  permettre  de  se 
focaliser  sur  ses  objectifs  prioritaires  et  de  simplifier  l'analyse  des  points  forts  et  des  points  faibles  de 
l'organisation.  (Selon  AFNOR  2004) 

Fiabilité 

Aptitude  d'un  système  à  accomplir  sans  défaillance  une  fonction  requise  dans  des  conditions  données, 
pendant  un  intervalle  donné 

Fidélisation 

Stratégie  marketing  destinée  à  conserver  les  clients  acquis  de  l'entreprise.  Le  coût  d'acquisition  d'un 
nouveau  client  étant  très  élevé,  c'est  une  stratégie  moins  coûteuse  qu'une  stratégie  d'acquisition  de 
nouveaux  clients.  (Selon  AFNOR  2004) 

Formulation  de  la  stratégie 

La  formulation  de  la  stratégie  consiste  à  décrire,  à  partir  d'une  analyse  de  l'environnement  de 
l'entreprise,  les  objectifs  qu'elle  s'assigne  et  les  moyens  à  mettre  en  œuvre  pour  y  parvenir.  Elle  se 
décline  en  plusieurs  volets  qui  précisent  les  objectifs  de  chaque  direction  ou  service.  Cette 
formalisation  est  utile  tant  en  interne  qu'en  externe  car  elle  permet  de  se  focaliser  sur  ce  qui  est 
important  pour  l'organisation  en  traçant  une  vision  de  l'avenir  et  la  place  que  l'organisation  aspire  à 
tenir.  La  stratégie  est  un  outil  fédérateur  qui  permet  de  mobiliser  les  énergies  autour  d'un  projet. 

(Selon  AFNOR  2004) 

Gantt 

Diagramme  présentant  les  tâches  et  leurs  durées  d'exécution  et  servant  à  analyser  les  problèmes  de 
délai  et  de  répartition  de  tâches  dans  les  projets  (Selon  Belot) 

Gestion  de  projet 
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(1)  Ensemble  des  outils  de  gestion  mis  à  la  disposition  du  groupe  de  projet,  pour  conduire  le  projet  en 
terme  de:  Performance  technique  /  Contrôle  de  coût  /  Qualité  /  Maîtrise  des  délais  (Selon  Aim  2007) 

(2)  Ensemble  de  processus  comportant  des  procédures,  des  techniques  et  des  outils,  par  lesquels  un 
projet  sera  géré  du  début  à  la  fin,  pour  que  les  objectifs  prédéfinis  par  le  client  soient  atteints. 

(3)  Application  de  connaissances,  de  compétences,  d'outils  et  de  techniques  aux  activités  d'un  projet 
afin  d'en  satisfaire  les  exigences  (Selon  PMBoK  2008) 

Gestion  de  portefeuille  de  projets  (GPP) 

Gestion  centralisée  d'un  ou  plusieurs  portefeuilles  dans  le  but  d'atteindre  des  objectifs  d'affaires 
stratégiques  particuliers.  (Selon  PMBoK  2008) 

Gestion  des  coûts 

voir  coûtenance  (Selon  AFNOR  1996) 

Gestionnaire  de  processus 

Les  responsabilités  du  gestionnaire  de  processus  comprennent  la  planification  et  la  coordination  de 
toutes  les  activités  nécessaires  à  son  fonctionnement,  sa  surveillance  et  l'établissement  de  tableaux  de 
bords  sur  le  fonctionnement  du  processus.  Le  rôle  du  gestionnaire  de  processus  est  souvent  confondu 
avec  celui  de  propriétaire  du  processus  (voir  Propriétaire  de  processus),  mais  ces  deux  rôles  peuvent 
être  distincts  dans  les  grandes  organisations 

Image  de  marque 

Ensemble  des  points  caractéristiques  qui  identifient  dans  l'esprit  du  public  un  produit  ou  une  marque. 
Ces  éléments  peuvent  être  objectifs  (qualités  techniques,  composition  du  produit,  prix,  circuit  de 
distribution. . .)  ou  subjectifs.  La  qualité  de  l'accueil  peut  être  un  élément  fondamental  pour  l'image  de 
marque  d'une  entreprise.  (Selon  AFNOR  2004) 

Impact 

Effet  d'une  campagne  de  communication  ou  d'une  action  de  promotion.  Cet  effet  peut  se  mesurer  de 
façon  quantitative,  (chiffre  d'affaires,  augmentation  du  nombre  de  clients. .  .ou  qualitative  (changement 
d'image  d'un  produit  ou  d'un  point  de  vente. . .)  (Selon  AFNOR  2004) 

Imputation 

Prise  en  compte  de  la  valeur  d'une  tâche  dans  un  calcul  plus  général  (budget,  coût  prévisionnel),  en  se 
conformant  au  code  des  coûts.  (Selon  AFNOR  1996) 

Indicateur 

Mesure  quantifiée  qui  permet  d'apprécier  de  manière  pertinente  les  réalisations  dans  un  domaine 
donné.  L'information  choisie  doit  être  associée  à  un  phénomène  et  elle  est  destinée  à  en  observer 
régulièrement  les  objectifs  au  regard  d'objectifs  prédéfinis.  (Selon  AFNOR  2004) 

Indicateur  de  qualité  interne 

Indicateur  de  mesure  de  la  qualité  effectivement  réalisée  par  rapport  aux  objectifs  visés  par 
l'organisme.  (Selon  AFNOR  2004) 

Indicateur  de  satisfaction 
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Indicateur  de  mesure  de  la  qualité  perçue  par  le  client  en  fonction  de  ses  attentes.  (Selon  AFNOR 
2004) 

Inflation 

Phénomène  économique  qui  fait  varier  dans  le  temps  le  coût  d'une  même  prestation,  calculée  dans  la 
même  monnaie.  C'est  en  fait,  une  dépréciation  de  la  valeur  de  cette  monnaie.  Selon  les  termes  du 
contrat,  la  hausse  des  coûts  est  prise  en  charge  par  le  vendeur,  l'acheteur  ou  bien  un  organisme 
d'assurance  (COFACE  par  exemple).  Le  poste  budgétaire  qui  prend  en  compte  ce  phénomène  est  bien 
souvent  le  plus  gros  poste  de  tout  le  budget  et  dépend  à  la  fois  des  règles  comptables  de  la  société,  et 
de  la  forme  du  contrat.  (Selon  AFNOR  1996) 

Jalon 

Un  jalon  (ou,  en  anglais  "milestone"),  dans  le  cadre  de  la  gestion  de  projet,  est  la  fin  d'une  étape,  la  fin 
d'un  travail.  La  plupart  du  temps,  le  jalon  est  aussi  un  événement  important,  comme  la  signature  d'un 
contrat,  le  lancement  d'un  produit...  De  nombreuses  méthodes  et  outils  de  gestion  de  projet  définissent 
le  jalon  comme  une  tâche  de  durée  nulle.  Cette  définition  technique  est  réductrice  car  le  jalon  a  sa 
place  à  part  dans  la  gestion  de  projet  et  il  est  possible  de  piloter  un  projet  ou  un  portefeuille  par  les 
jalons. 

Leadership  situationnel 

Modèle  permettant  au  chargé  de  projet  d'adopter  un  comportement  adapté  à  la  réalité  vécue  sur  le 
terrain  par  les  membres  de  l'équipe. 

Lot  de  travaux  (LT) 

Le  lot  de  travaux  est  l'élément  le  plus  détaillé  apparaissant  dans  un  organigramme  des  tâches  (OT).  Le 
LT  est  caractérisé  par  une  définition  du  travail  à  réaliser,  un  responsable  unique,  un  budget  et  des 
éléments  de  délais,  soit  une  durée,  soit  des  liaisons  avec  les  autres  LT  antérieurs  ou  postérieurs.  (Selon 
AFNOR  1996) 

Maintenabilité 

Probabilité  qu'une  opération  de  maintenance  puisse  être  effectuée  dans  des  conditions  données,  pour 
un  intervalle  donné 

Maître  d’œuvre 

(1)  Responsable  de  la  réalisation  du  projet.  Il  s'engage  sur  des  objectifs  de  coûts,  de  qualité,  de  délais. 
Il  assure  le  choix,  la  coordination,  la  mise  en  œuvre  effective  des  différents  moyens.  Selon  les  cas,  le 
maître  d'œuvre  peut  être  un  responsable  de  projet  (interne  à  l'entreprise)  ou  une  société  prestataire  de 
services. 

(2)  Ne  pas  confondre  avec  le  terme  suivant.  C'était,  de  tous  temps,  depuis  les  bâtisseurs  de  cathédrales, 
la  personne  physique  qui  avait  la  charge  de  concevoir  et  de  mener  à  bien  la  construction  de  l'ouvrage 
dans  l'acception  artistique  du  terme,  et  donc  de  conduire  l'œuvre  à  bonne  fin.  Le  maître  d'œuvre  était 
alors  personnifié  par  l'architecte.  (Selon  AFNOR  1996) 

Maître  d’ouvrage 

(1)  Client  (Individu  ou  entreprise)  qui  décide  de  confier  la  réalisation  d'un  projet  à  un  maître  d'œuvre. 
Le  maître  d'ouvrage  doit  définir  ses  besoins  à  travers  un  cahier  des  charges;  le  respect  de  ce  cahier  des 
charges  est  de  la  responsabilité  du  maître  d'œuvre. 
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(2)  C'est  la  personne  physique  ou,  le  plus  souvent,  la  personne  morale  qui  sera  le  propriétaire  de 
l'ouvrage.  Il  fixe  les  objectifs,  l'enveloppe  budgétaire  et  les  délais  souhaités  pour  le  projet.  Dans 
certains  cas,  le  maître  d'ouvrage  délègue  tout  ou  partie  de  ses  pouvoirs  à  un  mandataire  et  notamment 
lorsqu'il  s'agit  d'une  administration  ou  d'une  collectivité  locale.  Néanmoins,  c'est  lui  qui  en  est 
finalement  responsable  après  le  transfert  de  propriété  et  qui  assure  le  paiement  des  dépenses  liées  à  la 
réalisation.  (Selon  AFNOR  1996) 

Maîtrise  des  coûts  (Coutenance)  (En  anglais  'Cost  control') 

Processus  permettant,  durant  toute  la  durée  d'un  projet  de  prévoir,  suivre  et  optimiser  tous  les  coûts  des 
activités  successives  avec  l'objectif  de  maîtriser  un  coût  prévisionnel  final  (NF  X50-106-1) 

Mandataire 

Personne  chargée  d'en  représenter  une  autre  (le  mandant)  pour  accomplir  des  actes  juridiques  en  son 
nom  et  pour  son  compte.  (Selon  AFNOR  1996 ) 

Marché  au  forfait 

Obligation  de  résultats  lors  d'appel  d'offre 

Marché  en  régie 

Obligation  de  moyens  lors  d'appel  d'offre 

Marketing-mix 

Ensemble  des  composantes  de  l'offre  de  service  qui  doivent  être  proposées  en  synergie  à  chaque 
segment  visé  par  une  entreprise.  Les  quatre  composantes  classiques  du  marketing-mix  sont:  le  produit, 
le  prix,  la  communication  et  la  publicité.  C'est  le  choix  et  le  dosage  de  ces  moyens  qui  sont  le  gage  des 
plans  de  marketing.  (Selon  AFNOR  2004) 

Mode  projet 

Concept  intégrant  les  facteurs  organisationnels  habilitants  de  la  gestion  de  projet,  le  bureau  de  projet, 
l'amélioration  des  pratiques,  la  gestion  du  portefeuille  de  projet  <GPP>,  la  gestion  des  programmes,  la 
gestion  des  projets  et  l'évaluation  des  résultats. 

Norme 

Une  norme  industrielle  industrielle  ou  méthodologique  est  un  référentiel  publié  par  unorganisme  de 
normalisation  officiel  comme  l'AFNOR,  ISO,  IEEE,  etc.  Un  standard  est  un  référentiel  ayant  une 
diffusion  large.  Aux  États-Unis  on  utilise  le  terme  "standard"  au  lieu  de  "norme",  d'où  la  confusion 
parfois  entre  les  deux  dans  le  monde  francophone. 

Notoriété 

Le  taux  de  notoriété  est  le  degré  de  connaissance  d'une  marque  ou  d'un  produit.  Le  taux  est  mesuré 
par  le  pourcentage  d'individus  d'une  population  donnée  connaissant  la  marque  considérée.  Ce  taux 
peut  être  mesuré  en  spontané  ou  en  assisté.  (Selon  AFNOR  2004) 

Oeuvre 

C'est  le  processus  de  réalisation  de  l'ouvrage  c'est-à-dire  la  mise  en  place  des  moyens  nécessaires  à 
cette  réalisation  et  leur  conduite.  L'œuvre  est  constituée  de  l'ensemble  des  tâches,  regroupées  ou  non 
en  lots  de  travaux.  (Selon  AFNOR  1996) 
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Vincent  ISOZ 


Offre,  Proposition 

Réponse  à  une  consultation  émanant  d'un  client  potentiel  sous  la  forme  d'un  appel  d'offres  en  bonne  et 
due  forme,  d'une  demande  écrite  ou  même  verbale.  L 'offre  comporte  une  description  technique 
définissant  l'objet,  une  partie  organisationnelle  et  une  partie  juridico-commerciale  concernant  les 
conditions  de  cession  de  l'objet;  cette  partie  inclut  le  devis.  (Selon  AFNOR  1996) 

Organigramme  des  tâches  (OT/WBS) 

Découpage  hiérarchisé  et  arborescent  de  l'œuvre  en  éléments  plus  faciles  à  analyser  et  à  maîtriser, 
appelés  lots  de  travaux  (LT)  ou  tâches.  Il  doit  répondre  aux  deux  questions:  Que  doit-on  faire? 
Comment  doit-on  s'y  prendre?  (Selon  AFNOR  1996) 

Organigramme  fonctionnel  (OF/OBS) 

Organigramme  représentant  la  structure  des  différents  niveaux  de  responsabilités  de  réalisation  de 
l'ensemble  des  lots  de  travaux  (LT)  d'un  même  organigramme  des  tâches  (OT).  Lorsque  le  projet 
utilise  des  intervenants  divers  dans  des  entreprises  différentes,  c'est  la  structure  de  ces  entreprises  qui 
est  décrite  dans  l'OF.  Ne  pas  confondre  avec  l'arborescence  fonction.  (Selon  AFNOR  1996) 

Organigramme  technique  (SYN:  Organigramme  de  tâche)  (En  anglais:  WBS 

Work  Breakdown  Structure) 

Division  du  travail  de  projets  complexes  en  lots  de  tâches  (Work  package),  qui  sont  affectés  aux 
responsables  de  structure  industrielle  (ou  OBS  Organizational  Breakdown  Structure),  qui  doivent 
respecter  les  délais  et  les  coûts 

Origine  du  projet 

Les  projets  sont  habituellement  autorisés  à  la  suite  d'une  ou  de  plusieurs  considération(s)  stratégique(s) 
suivante(s):  Demande  du  marché  /  Besoin  d'affaires  ou  Opportunité  stratégique  /  Demande  des  clients  / 
Avance  technologique  /  Obligation  légale  (Selon  PMBoK  2008) 

Paiement 

Dans  le  cadre  d'un  projet,  les  paiements  correspondent  aux  débours  réels.  (Selon  AFNOR  1996) 

Panel 

Echantillon  permanent  d'une  population  (individus,  ménages,  distributeurs. . .)  que  l'on  interroge  à 
intervalles  réguliers  pour  suivre  leurs  changements  de  comportement.  (Selon  AFNOR  2004) 

Part  de  marché 

Fraction  (exprimée  en  pourcentage)  du  total  des  ventes  d'une  profession,  qui  est  réalisée  par  une 
entreprise  particulière.  (Selon  AFNOR  2004) 

Partie  prenante 

(1)  Toutes  entités  susceptibles  d'être  intéressées  par  la  réalisation  du  projet  ou  l'existence  de  l'ouvrage. 
Comprend  non  seulement  le  maître  d'ouvrage  et  les  intervenants,  mais  souvent,  aussi,  l'administration, 
le  public,  les  utilisateurs  du  produit,  etc.  (Selon  AFNOR  1996) 

(2)  Personne  physique  ou  morale  (organisation)  qui  prend  une  part  active  au  projet  et  dont  les  intérêts 
peuvent  être  affectés,  positivement  ou  négativement,  par  la  performance  du  projet  ou  son  achèvement. 
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Les  parties  prenantes  peuvent  également  avoir  une  influence  sur  le  projet,  ses  livrables  et  les  membres 
de  l'équipe  de  projet  (Selon  PMBoK  2008) 

Performance 

Attribut  d'un  produit,  ou  d'un  processus  qui  reflète  son  aptitude  à  atteindre  le  ou  les  objectifs  qui  lui 
sont  assignés.  ( Selon  AFNOR  2004) 

PERT 

(Signifie:  Program  of  Evaluation  and  Review  Technique  — OU —  Program  of  Evaluation  and  Review 
Task) 

Procédé  de  planification,  utilisé  pour  des  projets  comportant  de  nombreuses  tâches  interdépendantes, 
affichant  des  vecteurs  (tâches),  ainsi  que  sommets  (indication  de  début  ou  fin  de  tâche).  L'ordre 
d'enchaînement  des  vecteurs  donne  les  contraintes  de  succession  et  indique  le  respect  de  l'exigence  de 
«posteriori  stricte». 

Pessimiste  (durée,  coût,  scénario) 

Estimation  consistant  à  prendre  en  compte  les  événements  les  plus  défavorables  uniques  ou  cumulés 
pour  estimer  la  durée,  le  coût  ou  un  scénario  d'une  mesure  quantifiable  d'un  projet.  Le  concept  de 
pessimiste  est  à  l'opposé  de  celui  d'optimiste. 

Phase 

La  phase  est  une  subdivision  importante  et  significative  d'un  projet.  On  peut,  sans  que  cela  soit  une 
obligation,  identifier  par  exemple  trois  grandes  phases :  -La  définition,  qui  va  de  l'idée  initiale  jusqu'à 
la  décision  de  réaliser,  avec  désignation  du  réalisateur;  elle  peut  comporter  des  études  de  faisabilité  et 
conception,  des  procédures  d'autorisation  et  de  négociations  contractuelles;  elle  est  totalement  du 
ressort  du  maître  d'ouvrage,  même  si  celui-ci  la  délègue  parfois  à  son  futur  maître  d'œuvre.  -La 
réalisation,  qui  va  de  la  décision  de  confier  l'œuvre  à  un  maître  d'œuvre  jusqu'à  la  réception  du  projet; 
elle  comporte  en  général  des  études,  des  approvisionnements  et  des  travaux.  -La  mise  en  exploitation 
de  l'ouvrage,  ou  l'industrialisation  du  prototype  qui  doit  prouver  que  le  projet  a  bien  atteint  ses 
objectifs.  (Selon  AFNOR  1996) 

Plan  de  projet 

Document  définissant  les  modes  d'exécution  du  projet  et  qui  permet  au  chargé  de  projet  de  créer  la 
planification  initiale  des  tâches  à  réaliser  pour  compléter  le  projet  (Selon  Lalonde  2008) 

Planning  projet  (En  anglais:  Time  scheduling) 

Représentation  calendaire  indiquant  l'enchaînement  logique  des  tâches  à  réaliser  et  les  jalons  (Selon 
Aim) 

PMBoK  (Project  Management  Body  of  Knowledge) 

Guide  du  Corpus  de  connaissances  en  gestion  de  projet,  décrivant  les  normes,  méthodes,  processus  et 
pratiques  généralement  reconnues,  permettant  de  gérer  un  projet  individuel. 

Portefeuille  de  projet 

(1)  Ensemble  de  tous  les  programmes  et  de  tous  les  projets  que  l'organisation  compte  effectuer  durant 
une  période  déterminée.  (Selon  Lalonde  2008) 
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(2)  Ensemble  de  projets  ou  de  programmes,  ainsi  que  d'autres  travaux  qui  sont  regroupés  pour  faciliter 
un  management  efficace  de  ces  travaux,  dans  la  poursuite  d'objectifs  stratégiques  de  l'organisation 
(Selon  PMBoK  2008) 

Positionner 

Positionner,  c'est  concevoir  la  façon  dont  le  produit  ou  le  service  sera  présenté  à  la  cible  et  mettre  en 
valeur  tel  ou  tel  élément  de  l'offre  face  à  la  concurrence  de  façon  à  lui  donner  une  certaine  perception 
dans  l'esprit  du  futur  client.  Positionner  un  produit  ou  un  service  suppose  que  l'on  ait  préalablement 
ciblé  son  marché.  (Selon  AFNOR  2004) 

Positionnement 

Situation  d'un  produit  ou  d'un  canal  de  distribution  par  le  client  parmi  les  différentes  marques 
concurrentes.  Les  entreprises  analysent  ce  positionnement  afin  de  la  conforter  dans  l'esprit  du  public 
ou  de  rechercher  un  positionnement  plus  favorable.  (Selon  AFNOR  2004) 

Prévision 

En  cours  de  réalisation,  estimation  aussi  objective  que  possible  de  ce  que  seront  le  coût  et  le  délai  réels 
d'une  tâche  à  son  achèvement.  Cette  prévision  diffère  souvent  du  budget  et  ne  doit  pas  inclure  les 
provisions  pour  risques  résiduels,  comptées  séparément.  (Selon  AFNOR  1996) 

Prix 

Equivalent  monétaire  d'un  produit  ou  d'un  service,  lors  d'une  transaction  commerciale.  Le  prix  qui  est 
le  même  pour  le  client  et  le  vendeur,  devient  un  élément  de  coût  pour  le  client.  (Selon  AFNOR  1996) 

Prix  de  cotation 

Montant  inscrit  dans  l'offre,  avant  négociation.  (Selon  AFNOR  1996) 

Prix  définitif 

Prix  maintenu  ferme  jusqu'à  l'achèvement  complet  des  prestations  ou  du  contrat.  (Selon  AFNOR  1996) 

Prix  de  vente 

Montant  initial  des  recettes  à  la  signature  du  contrat,  après  négociation  (à  distinguer  du  prix  de 
cotation!)  (Selon  AFNOR  1996) 

Prix  ferme 

Prix  non  susceptible  d'être  modifié,  sauf  sur  ce  qui  concerne  la  révision  pour  inflation,  suivant  une 
formule  convenue.  (Selon  AFNOR  1996) 

Prix  fixe 

Prix  non  susceptible  de  révision  ou  de  mise  à  jour  pour  quelque  motif  que  ce  soit,  pendant  un  période 
donnée  (délai  d'option).  (Selon  AFNOR  1996) 

Programme  de  projets 

(1)  Groupe  de  projets  reliés  qui  obtiennent  des  avantages  à  être  gérés  en  commun.  (Selon  Lalonde 
2008) 
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(2)  Groupe  de  projets  apparentés  dont  le  management  est  coordonné,  afin  d'en  tirer  des  avantages  et 
une  maîtrise  que  n'apporterait  pas  un  management  individuel.  (Selon  PMBoK  2008) 


Vincent  ISOZ 


(3)Ensemble  de  projets  ou  familles  de  projets  (Selon  Aim  2007) 


Projet 


(1)  Réalisation  temporaire  et  unique  nécessitant  des  ressources  pour  atteindre  un  but  bien  défini  et 
tenant  compte  des  contraintes  de  temps,  de  coûts  et  de  contenu.  C'est  donc  se  projeter  dans  le  futur  et 
planifier  des  actions  pour  parvenir  à  un  objectif  précis  et  établi.  (Selon  Lalonde  2008) 

(2)  Effort  temporaire  exercé  dans  le  but  de  créer  un  produit,  un  service  ou  un  résultat  unique.  (Selon 
PMBoK  2008) 

(3)  Démarche  spécifique  permettant  de  structurer  méthodiquement  et  progressivement  une  réalité  à 
venir  (NF  X50-105) 

(4)  Ensemble  d'actions  à  réaliser  pour  satisfaire  un  objet  défini  dans  le  cadre  d'une  mission  précise  et 
pour  la  réalisation  desquelles  on  a  identifié  un  début  et  une  fin.  (Selon  AFITEP) 

(5)  Processus  unique,  qui  consiste  en  un  ensemble  d'activités  coordonnées  et  maîtrisées,  comportant 
des  dates  de  début  et  de  fin,  entrepris  dans  le  but  d'atteindre  un  objectif  conforme  à  des  exigences 
spécifiques,  incluant  des  contraintes  de  délais,  de  coûts  et  de  ressources  (NF  50-105) 

(6)  Un  projet  est  défini  et  mis  en  œuvre  pour  élaborer  la  réponse  au  besoin  d'un  utilisateur,  d'un  client 
ou  d'une  clientèle  et  il  implique  un  objectif  et  des  actions  à  entreprendre  avec  des  ressources  données 
(NF  X50-150) 

(7)  Unique,  transient  endeavor,  undertake  to  achieve  a  desired  outcome  (Ref:  British  Standard  Project 
Management  Vocabulary.  Cité  par:  Association  for  Project  Management  -  UK) 

Propriétaire  de  processus 

Les  responsabilités  du  propriétaire  de  processus  comprennent  la  recherche  de  sponsors,  la  conception, 
la  documentation,  la  gestion  des  changements,  l'amélioration  continue,  le  contrôle  du  respect,  la 
formation  du  processus  et  de  ses  mesures.  Ce  rôle  est  souvent  confondu  avec  celui  de  gestionnaire  du 
processus  ( voir  Gestionnaire  de  processus),  mais  ces  deux  rôles  peuvent  être  distincts  dans  les  grandes 
organisations. 

Rapport  d’avancement 

Document  périodique  de  synthèse  décrivant:  -Les  événements  et  problèmes  principaux  rencontrés 
dans  la  période  écoulée,  -Le  travail  effectivement  réalisé  durant  cette  période  pour  chacune  des 
prestations  du  contrat,  -L'avancement  de  ce  dernier  par  rapport  au  travail  planifié  ou  au  travail  à 
effectuer,  -Le  travail  planifié  pour  la  période  suivante.  Les  avancements  sont  mesurés  par  des 
paramètres  physiques  (avancement  physique)  ou  par  leur  valeur,  et  peuvent  être  illustrés  par  des 
graphiques.  Les  données  sont  généralement  enregistrées  et  stockées  de  manière  à  pouvoir  constituer,  à 
la  réception  provisoire  du  contrat,  le  rapport  final  du  projet.  (Selon  AFNOR  1996) 

Rapport  de  coût  (En  anglais  'Cost  control') 

(1)  Document  périodique,  sous  forme  de  tableaux  et/ou  diagrammes,  récapitulant  pour  chacune  des 
lignes  budgétaire:  Budget  initial  et  ses  éventuelles  révisions  /  Engagement  à  une  date  donnée  / 
Estimation  des  coûts  futurs  /  Coût  total  prévisionnel  (son  écart  avec  le  budget  prévisionnel  révisé  et  sa 
dérive  par  rapport  au  précédent  coût  total  prévu  (Selon  Aim  2007) 
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(2)  Document  périodique  émis  par  le  coûteneur  pour  informer  la  direction  de  projet  des  écarts,  dérives 
et  tendances.  Les  éléments  figurant  dans  ce  rapport  sont  préparés,  ligne  budgétaire  par  ligne 
budgétaire,  selon  la  logique  ci-dessous  et  récapitulés  par  grands  chapitres,  en  coûts  secs.  On  en  déduit 
une  estimation  des  provisions  de  projet  à  conserver  et,  par  différence  avec  les  recettes  attendues, 
diminuées  des  charges  générales,  une  prévision  des  marges  attendues.  Ce  rapport  peut  être 
accompagné  d'un  échéancier  calendaire  des  paiements  à  effectuer  par  le  maître  d'ouvrage.  (Selon 
AFNOR  1996) 

Réactivité 

Capacité  d'une  entreprise  à  répondre  par  une  action  réfléchie  à  un  changement  de  son  environnement. 
Elle  nécessite  d'une  part  la  mise  en  place  d'un  système  de  veille  stratégique  et  concurrentielle  et  d'autre 
part  une  organisation  capable  de  se  mobiliser  rapidement  pour  trouver  des  solutions  et  les  mettre  en 
œuvre.  (Selon  AFNOR  2004) 

Recettes  prévisionnelles 

Par  définition,  les  recettes  prévisionnelles  sont,  à  un  instant  donné,  le  montant  le  plus 
vraisemblablement  encaissable.  Les  recettes  sont  exprimées  dans  les  bases  économiques  choisies  pour 
l'évaluation  du  coût  prévisionnel.  Les  recettes  prévisionnelles  se  subdivisent  en: 

(1)  Recettes  contractuelles  qui  correspondent:  -pour  les  postes  du  contrat  à  prix  forfaitaire,  aux 
montants  contractuels  éventuellement  corrigés  par  les  avenants  signés,  -pour  les  postes  du  contrat  à 
prix  de  bordereau,  à  la  valorisation  aux  taux  contractuels,  du  dernier  métré  estimatif  approuvé  par  le 
client. 

(2)  Pénalités  et  bonus  qui  correspondent  à  la  valorisation,  aux  taux  contractuels,  des  plus  récentes 
estimations  en  matière  de  planning  et  de  performances. 

(3)  Recettes  espérées  qui  correspondent  aux  montants  que  le  responsable  de  projet  pense  pouvoir 
obtenir  du  client  concernant  les  suppléments  et  avenants  en  cours  de  négociation  et  les  réclamations 
introduites  ou  à  introduire. 

(4)  Les  recettes  prévisionnelles  sont  exprimées  dans  la  monnaie  contractuelle  à  laquelle  elles 
correspondent.  (Selon  AFNOR  1996) 

Reformulation 

Action  qui  consiste  à  répéter  dans  ses  propres  termes  les  propos  du  client  afin  de  s'assurer  d'une  bonne 
compréhension  et  permettre  à  une  discussion  de  se  dérouler  de  façon  positive.  (Selon  AFNOR  2004) 

Reporting 

Il  n'y  a  pas  en  français  de  mot  pour  dire  «  les  actions  relatives  à  la  préparation  et  à  la  présentation  des 
rapports  relatifs  à  un  projet  ».  Le  reporting  consiste,  pour  le  responsable  de  projet,  à  rendre  compte,  à 
intervalles  définis,  aussi  bien  à  sa  hiérarchie  qu'à  son  client,  de  la  façon  dont  le  projet  se  déroule  sur 
tous  les  plans,  en  particulier  délais,  avancement,  coût,  par  rapport  aux  prévisions  précédentes.  On  peut 
distinguer  divers  types  de  rapports  servant  au  reporting: 

-Rapports  d’avancement  des  spécialistes  (en  anglais:  progress  report):  donnant  essentiellement  leur 
avancement  physique.  Ces  rapports  sont  habituellement  internes  au  projet.  Ils  ne  sont  donc  pas 
destinés  au  client. 

-Rapport  financier  (en  anglais:  cost  report),  préparé  par  le  gestionnaire  du  projet,  et  donnant 
essentiellement  les  informations  de  coût  de  revient,  de  prix  de  vente,  d'engagements  et  de  facturation 
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au  client;  De  plus  en  plus,  ce  rapport  donne  l'état  de  la  trésorerie  du  projet.  Ce  rapport  est  également 
interne,  sauf  si  le  contrat  prévoit  qu'il  soit  remis  au  client  (contrat  du  type  en  dépenses  contrôlées). 

-Rapport  du  projet  (en  anglais:  project  report).  Ce  rapport  est  périodique  (mensuel  en  général, 
trimestriel  pour  les  projets  très  longs).  Rédigé  par  le  responsable  de  projet  en  utilisant  les  rapports 
précédents,  il  est  destiné  à  son  client.  Il  porte  sur  tous  les  aspects  mentionnés  plus  haut.  (Selon 
AFNOR  1996) 

Responsable  des  opérations 

Personne  chargée  d'un  aspect  des  activités  de  base  de  l'entreprise,  comme  par  exemple,  la  R&D,  la 
conception,  la  fabrication,  l'approvisionnement,  les  essais  ou  l'entretien  (Selon  PMBoK  2008) 

Responsable  fonctionnel 

Personne  qui  concentre  son  travail  de  management  dans  la  partie  administrative  ou  fonctionnelle  de 
l'organisation,  comme  par  exemple,  les  ressources  humaines,  la  finance,  la  comptabilité  ou  les 
approvisionnements  (Selon  PMBoK  2008) 

Retour  d’information 

Informations  conformes  à  la  réalisation,  établies  de  façon  à  pouvoir  être  mises  en  parallèle  avec  les 
hypothèses  initiales  d'une  part,  et  d'autre  part,  être  stockées  dans  une  base  de  données  comparable. 
(Selon  AFNOR  1996) 

Révision  de  prix 

En  cours  d'exécution  du  contrat,  la  révision  est  le  calcul  de  l'augmentation  du  prix  des  prestations  en 
fonction  de  la  variation,  à  partir  d'une  date  de  référence,  des  conditions  économiques.  Elle  s'appuie  sur 
des  indices  de  référence  et  comporte  en  général  une  partie  fixe.  (Selon  AFNOR  1996) 

Revue  de  projet 

Examen  entrepris  pour  déterminer  la  pertinence  de  ce  qui  est  examiné,  son  adéquation  et  son  efficacité 
à  atteindre  les  objectifs. 

Risque 

C'est  la  possibilité  qu'un  projet  ne  s'exécute  pas  conformément  aux  prévisions  de  dates  d'achèvement, 
de  coût  et  de  spécifications,  ces  écarts  par  rapport  aux  prévisions  étant  considérés  comme  difficilement 
acceptables,  voire  inacceptables.  Le  risque  résulte  ou  d'un  aléa,  ou  d'une  incertitude,  ou  encore  d'un 
imprévu.  (Selon  AFNOR  1996) 

Satisfaction 

Opinion  d'un  client  résultant  de  l'écart  entre  sa  perception  du  produit  ou  service  consommé  et  ses 
attentes.  (Selon  AFNOR  2004) 

Sécurité 

État  dans  lequel  le  risque  de  dommages  corporels  et  matériels  est  limité  à  un  niveau  acceptable  (NF 
EN  ISO  8402) 

Segmentation 
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Le  marketing  reconnaît  qu'un  marché  ne  peux  pas  être  considéré  comme  homogène  et  qu'il  est 
nécessaire  d'adapter  le  produit  à  chaque  besoin  des  clients  visés  par  l'entreprise.  La  segmentation  est 
donc  la  méthode  de  découpage  du  marché  en  groupe  de  clients  recherchant  dans  chaque  produit  ou 
service  un  ensemble  d'attributs  et  ayant  des  réactions  comparables  face  à  une  action  commerciale. 
(Selon  AFNOR  2004) 

Service 

Résultat  d'un  processus.  Un  service  est  le  résultat  d'au  moins  une  activité  nécessairement  réalisée  à 
l'interface  entre  le  fournisseur  et  le  client  et  est  généralement  immatériel.  (Selon  AFNOR  2004). 

Un  service  est  une  manière  de  délivrer  de  la  valeur  à  un  client  en  facilitant  l'obtention  de  ses  résultats 
tout  en  lui  épargnant  la  propriété  des  coûts  et  des  risques  spécifiques  y  étant  associés.  ( Selon  ITIL 
2011) 

Service  attendu 

Service  souhaité  par  le  client  en  réponse  à  ses  besoins  et  attentes.  (Selon  AFNOR  2004) 

Service  perçu 

La  perception  par  le  client  du  service  réalisé,  avec  ce  que  cela  comporte  de  subjectivité  et 
d'impondérable.  (Selon  AFNOR  2004) 

Service  request 

C'est  une  demande  qui  n'implique  pas  de  changement  d'un  Configuration  Item  (CI). 

Une  demande  de  service  est  une  demande  d'aide  (p.ex.:  demande  de  réinitialisation  d'un  mot  de  passe 
oublié,  demande  d'informations  en  général,  demande  de  l'état  d'un  incident  annoncé,  etc.) 

Service  réalisé 

Caractéristique  du  service  réellement  réalisé  par  l'organisme.  (Selon  AFNOR  2004) 

Service  voulu 

Caractéristique  du  service  que  l'organisme  souhaite  atteindre  pour  répondre  à  sa  stratégie  et 
correspondant  aux  attentes  des  clients.  (Selon  AFNOR  2004) 

Sondage 

Prélèvement  dans  une  population  d'un  échantillon  qui  va  servir  de  point  de  référence  pour  décrire  la 
population  dans  son  ensemble.  (Selon  AFNOR  2004) 

Spectacle  (ENG:  Show) 

Représentation  (théâtrale,  musicale,  cinématographique,  etc.)  présentée  au  public  et  destinée  à  le 
divertir. 

Stratégie 

C'est  l'art  de  faire  évoluer  l'organisation  dans  un  environnement  donné  pour  la  rendre  la  plus  efficace 
possible  dans  l'accomplissement  de  ses  missions.  (Selon  AFNOR  2004) 

Structure  fonctionnelle 
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Somme  totale  des  moyens  employés  pour  diviser  le  travail  en  tâches  distinctes,  pour  ensuite  assurer  la 
coordination  entre  ces  tâches 

Structure  de  découpage  de  projet  (SDP  ou  WBS) 

Outil  de  planification  de  projet  permettant  de  subdiviser  le  travail  en  plus  petites  parties. 

Sûreté  de  fonctionnement 

Ensemble  des  propriétés  qui  décrivent  les  facteurs  qui  conditionnent:  la  disponibilité,  la  fiabilité,  la 
maintenabilité  et  la  logistique  de  maintenance 

Tableau  de  bord 

Outil  de  pilotage  et  d'aide  à  la  décision  regroupant  une  sélection  d'indicateurs.  Il  est  un  outil 
indispensable  pour  le  suivi  des  objectifs  et  la  mise  en  œuvre  d'actions  correctives. 

Tâche 

Action  d'une  ampleur  limitée,  la  tâche  appartient  à  un  métier  donné  et  correspond  généralement  à  une 
division  de  l'activité;  ses  caractéristiques,  en  particulier  quantitatives  (coût  et  durée),  peuvent  faire 
l'objet  de  séries  statistiques  qui  donnent  lieu  à  un  calcul  de  probabilités.  C'est  l'élément  le  plus  fin  d'un 
planning  de  réalisation.  (Selon  AFNOR  1996) 

Tendance 

On  appelle  tendance,  toute  cause  d'impact,  positif  ou  négatif,  sur  le  coût  prévisionnel  du  projet,  mais 
ne  pouvant  être  prise  en  compte  au  niveau  des  lignes  budgétaires  (soit  parce  que  la  probabilité  n'est 
pas  totale,  soit  parce  que  le  montant  ne  peut  être  estimé  avec  suffisamment  de  précision).  (Selon 
AFNOR  1996) 

Trafic  (création  de) 

Action  qui  a  pour  objectif  de  générer  des  visites  sur  un  lieu  de  vente  ou  dans  un  salon.  Elle  est 
souvent  réalisée  à  partir  de  publipostage  et  de  télémarketing.  Pour  les  sites  internet,  la  création  de 
trafic  est  souvent  générée  grâce  aux  liens  entre  les  sites  et  aux  bandeaux  publicitaires.  (Selon  AFNOR 
2004) 

Utilisateur 

Personne  (client,  usager,  administré. . .)  qui  entre  en  contact  avec  une  entité  pour  exprimer  une 
demande  et  obtenir  une  prestation  de  service.  (Selon  AFNOR  2004) 

Valeur  budgétaire 

En  cours  de  réalisation,  le  coût  réel  d'une  ligne  budgétaire  quelconque  est  rarement  celui  prévu  au 
budget.  Pour  bien  distinguer  dans  le  suivi  des  écarts,  ce  qui  est  dû  à  ces  variations  de  ce  qui  est  dû  aux 
retards  d'exécution,  il  est  convenu  de  faire,  dans  les  rapports  de  coûts,  le  calcul  du  réalisé  sur  la  base 
des  prix  unitaires  du  budget  initial,  d'où  la  notion  intermédiaire  de  coût  budgété  du  travail  effectué. 
(Selon  AFNOR  1996) 

Veille 

Etat  de  vigilance  permettant  la  collecter,  l'exploitation  et  la  diffusion  sélective  et  permanente 
d'informations  sur  l'environnement  d'une  organisation  sous  tous  ses  aspects  (économiques,  culturels, 
sociaux,  historiques,  écologiques. . .).  «  Activité  continue  et  en  grande  partie  itérative  visant  à  une 
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surveillance  active  de  l'environnement  technologique,  commercial,  etc.,  pour  anticiper  les  évolution  » 
(Selon  AFNOR  2004) 


Workaround 

Solution  provisoire  qui  soulage  une  erreur,  de  cause  inconnue  ou  connue  mais  qui  n'a  pas  encore  de 
solution  définitive. 
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